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EXECUTIVE  SUMMARY 


This  specification  establishes  design  criteria  for  a  Sector  Workload 
Probe  algorithm,  which  is  part  of  the  initial  automation  for  the 
Advanced  Automation  System  of  the  Federal  Aviation  Administration's 
Air  Traffic  Control 'tATC)N‘  System.  This  algorithm  calculates 
measures  related  to  workload.  The  algorithm  takes  into  account  a 
variety  of  measures.  These  measures  Include  the  following: 


average  aircraft  count  j 


number  of  expected  aircraft  or  airspace  conflicts  (as 
generated  by  two  other  advanced  automation  algorithms, 
Flight  Plan  Conflict  Probe  and  Airspace  Probe) j 


a  measure  of  actions  which  must  be  carried  out  by  controllers J 
a  density  measure ^ 


an  overall  measure  , 


For  every  sector,  each  measure  is  projected  for  various  time 
intervals  of  approximately  15  minutes  up  to  about  two  hours  in  the 
future. 


An  Area  Supervisor  or  Area  Manager  may,  at  any  time,  request  a 
display  of  the  current  and  projected  workload  measures  for  a 
specified  sector  or  set  of  sectors.  Also,  the  Area  Supervisor  may 
monitor  selected  sector(s)  to  determine  if  certain  measures  exceed 
or  fall  below  thresholds  that  he  or  she  specifies.  ^ 
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1.  INTRODUCTION 


The  Federal  Aviation  Administration  (FAA)  is  currently  in  the 
process  of  developing  a_  new  computer  system,  called  the  Ad¬ 
vanced  Automation  System  (AAS).,  to  help  control  the  nation* s 
air  traffic.  The  AAS  will  consist  of  new  or  enhanced  hardware 
(i.e.,  Central  Processing  Units,  memories,  and  terminals)  and 
new  software. 

The  new  software  will  retain  most  or  all  of  the  functions  in 
the  existing  National  Airspace  System  (NAS)  En  Route  Stage  A 
software.  The  algorithms  will  need  to  be  recoded  and,  in  some 
cases,  revised.  In  addition,  the  new  AAS  software  will  contain 
several  new  functions  that  make  greater  use  of  the  capabilities 
of  automation  for  Air  Traffic  Control  (ATC).  When  fully  imple¬ 
mented,  these  new  functions  are  intended  to  detect  and  resolve 
many  routine  ATC  problems. 

The  initial  implementation  of  the  AAS ,  described  in  the  AAS 
Specification  [1],  will  provide  the  ability  to  detect  some  com¬ 
mon  ATC  problems.  To  meet  the  requirements  of  the  AAS,  several 
new  ATC  functions  need  to  be  postulated  and  described.  Four  of 
these  functions  are  described  in  this  document:  Trajectory 
Estimation,  Flight  Plan  Conflict  Probe,  Airspace  Probe,  and 
Sector  Workload  Probe  [Volumes  1,  2,  3,  and  4].  Together,  they 
represent  an  initial  level  of  automation  and  the  beginnings  of 
the  evolution  of  the  ATC  system  in  accordance  with  the  NAS  Plan 
[2].  The  NAS  Plan  presents  an  overview  of  the  complete  set  of 
changes  proposed  to  NAS  in  the  coming  decade. 

1.1  Purpose 

The  purpose  of  this  volume  is  to  identify  design  criteria  for 
Sector  Workload  Probe  (SWP).  SWP  is  one  of  the  advanced  auto¬ 
mation  functions  called  for  in  the  AAS  Specification.  These 
design  criteria  specified  in  this  volume  are  based  on  the 
existing  National  Airspace  System  (NAS)  and  the  specification 
of  the  AAS.  The  AAS  specification  describes  the  Sector  Work¬ 
load  Probe  function  and  proposes  some  high  level  requirements 
for  this  function. 

1.2  Scope 

This  algorithmic  specification  presents  design  criteria  for  a 
computational  framework  of  Sector  Workload  Probe.  The  frame¬ 
work  is  a  set  of  algorithms  which  collectively  describe  how  it 
*  may  be  possible  to  measure  the  workload  associated  with  the 
sectors  which  provide  air  traffic  control  services.  It  may 
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be  viewed  as  a  candidate  for  consideration  in  the  final 
design.  However,  it  is  not  intended  to  be  the  complete  final 
design  of  SHF  in  the  AAS. 

The  framework  establishes  the  requirements  for  input  and  output 
data  and  provides  a  description  of  the  flow  of  control  of  data 
as  it  is  transferred  from  input  to  output.  Some  of  the  prin¬ 
cipal  requirements  have  been  identified  in  the  "Operational  and 
Functional  Description  of  AERA  1.01"  [3].  To  the  extent  pos¬ 
sible,  the  data  are  discussed  us.ng  existing  NAS  terminology. 

1.3  Organization  of  This  Document 

The  remainder  of  Section  1  provides  a  description  of  Sector 
Workload  Probe’s  role  in  the  larger  ATC  context  and  in  future 
enhancements  of  the  ATC  system.  Both  the  operational  consider¬ 
ations  and  processing  methods  of  SWP  are  summarized.  Section  2 
defines  the  terminology  used  in  the  specification  and  discusses 
the  factors  which  influence  the  depign  of  the  algorithms. 

Descriptions  of  the  algorithms  are  contained  in  Section  3,  Sec¬ 
tor  Workload  Probe  Functional  Design,  and  in  Section  4, 
Detailed  Description.  The  Sector  Workload  Probe  Function,  like 
the  other  advanced  automation  functions,  is  divided  hierarchi¬ 
cally  into  suhfunctlona,  components  and  elements  (underlined 
words  in  Sections  1  and  2  are  critical  to  the  understanding  of 
this  specification  and  can  be  found  in  the  Glossary,  Appendix 
B).  Section  3  specifies  the  design,  environment,  and  assump¬ 
tions  of  the  subfunctions  (e.g. ,  the  Subject  Aircraft 
Workload),  and  outlines  their  components  (e.g..  Individual  Air¬ 
craft  Workload  Update) .  Section  4  provides  a  detailed 
description  of  each  subf unction' s  components,  including  their 
mission,  data  requirements,  and  some  processing  details,  and  in 
some  cases  Includes  a  discussion  of  a  component's  elements 
(e.g,,  Create  Subject  Sector  Time  Intervals). 

Appendix  A  defines  the  data  shared  by  the  various  subfunctions 
of  SWP.  (Similarly,  Volume  5  of  this  document  contains  the. 
global  data  shared  by  the  functions  defined  in  Volumes  1 
through  4).  Appendix  B,  as  mentioned  above,  contains  a  glos¬ 
sary  of  those  terms  that  are  critical  to  an  understanding  of 
this  specification. 

A  Program  Design  Language  (PDL)  which  describes  high  level  con¬ 
trol  logic  using  structured  English  is  used  as  needed  to 
describe  the  algorithms  in  this  specification.  A  description 
of  this  PDL  is  contained  in  Appendix  C.  Finally,  Appendix  D 
provides  a  complete  list  of  references. 
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1*4  Role  of  Sector  Workload  Probe  in  the  Overall  ATC  System 

This  section  discusses  some  of  the  features  of  the  current  ATC 
System,  describes  the  role  of  Sector  Workload  Probe  in  the  Ad¬ 
vanced  Automation  System,  and  Indicates  changes  to  SWP  that  may 
be  appropriate  when  enhancements  to  the  AAS  are  introduced. 

The  Sector  Workload  Probe  calculates  measures  related  to  work¬ 
load,  which  is  defined  as  any  task,  performed  by  personnel  to 
provide  air  traffic  control  services  to  aircraft. 

1.4.1  System  Context 

The  continental  United  States  airspace  is  partitioned  into  20 
centers  or  Air  Route  Traffic  Control  Centers  (ARTCCs),  which 
control  divisions  of  airspace  bounded  horizontally  by  polygons 
and  stretching  vertically  from  the  center  floor  to  60,000  ft. 
Each  center's  airspace  is  further  divided  into  areas,  which  in 
turn  are  divided  into  sectors.  Areas  and  sectors  are  polygonal 
regions  with  floors  (either  at  specified  altitudes  or  the 
ground)  and  ceilings.  The  number  of  sectors  within  an  area  may 
change  over  time  due  to  traffic  volume  changes  and  other  fac¬ 
tors.  Each  sector  at  any  time  is  composed  of  one  or  more 
indivisible  pirts,  which  are  called  basic  sectors  in  SWP.  The 
process  of  combining  or  decomblning  basic  sectors  is  called 
aectorlration.  A  combined  sector  consists  of  one  or  more  basic 
sectors  under  a  sectorlzation  plan. 

Each  sector  is  staffed  by  one  or  more  radar  controllers,  whose 
responsibilities  include  maintaining  aircraft  separation  stan¬ 
dards  and  delivering  maneuver  clearances  to  aircraft.  The  Area 
Supervisor  is  the  first  line  supervisor  of  radar  controllers  in 
an  area.  An  Area  Supervisor's  responsibilities  include  the 
assignment  of  controllers  to  operating  positions  among  the  sec¬ 
tors  in  an  area.  The  Area  Manager  is  the  second  line 
supervisor  of  the  radar  controllers  and  is  responsible  for 
determining  when  to  perform  a  sectorlzation.  The  Area  Manager 
and/or  an  Area  Supervisor  also  determine(s)  whether  to  alter 
the  number  of  controllers  assigned  to  an  area. 

Hereafter,  the  term  supervisor  will  designate  either  an  Area 
Supervisor  or  an  Area  Manager.  The  term  controller  shall 
include  radar  controllers,  but  exclude  supervisors. 

The  plans  of  the  Federal  Aviation  Administration  for  the  evolu¬ 
tion  of  Air  Traffic  Control  are  discussed  in  "Advanced 
Automation  System,  System  Level  Specification"  [1],  and  in 
"National  Airspace  System  Plan  (NASP):  Facilities,  T^uipment 
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and  Associated  Development"  [2],  According  to  the  NASP,  the 
"early  capabilities  [of  Automated  Air  Traffic  Control]  will 
include  .  .  .  workload  probe,  which  calculates  predicted  sector 
workload  for  use  by  [a]  supervisor  for  determining  sector 
staffing  levels  and  sectorization  for  workload  balancing." 
According  to  the  AAS,  the  probe  should  "analyze  the  workload 
for  each  sector  whenever  a  flight  plan  is  activated  or  amended, 
or  an  active  flight  plan  is  received  from  an  adjacent  facili¬ 
ty.  This  automated  ATC  function  shall  provide  information  to 
determine  whether  an  unacceptable  workload  will  be  imposed  on 
any  control  sector."  ftie  interpretation  of  these  statements 
used  in  this  specification  is  that  sector  workload  is  computed 
according  to  various  measures;  the  supervisor  may  request  to  be 
notified  when  one  or  more  measures  meets  conditions  specified 
by  him,  or  the  supervisor  may  simply  request  SWP  information  at 
any  time. 

A  workload  measure  or  measure  is  a  mathematical  function  which 
attempts  to  assign  numerical  values  to  one  or  more  aspects  of 
workload.  Sector  Workload  Probe  produces  a  set  of  workload 
measures  using  data  from  other  functions  of  the  Advanced  Auto¬ 
mation  System  as  input.  Together,  the  measures  account  for  as 
many  aspects  of  workload  as  possible,  subject  to  the  limita¬ 
tions  of  the  data  base. 

1.4. 1.1  Sector  Workload  Probe  and  AERA 


The  advanced  automation  functions  for  the  ATC  System  described 
in  this  document  and  in  the  other  algorithmic  specifications 
[Vols.  1,2,3],  are  part  of  an  automated  system  referred  to  as 
AERA  ("Automated  En  Route  Air  Traffic  Control").  AERA  is  to  be 
implemented  in  several  stages,  as  outlined  in  -"Evolution  of 
Advanced  ATC  Automation  Functions"  [4].  Sector  Workload  Probe 
will  be  implemented  as  part  of  the  first  stage,  known  as  AERA  1 
(subdivided  into  AERA  1.01  and  AERA  1.02).  Operational  des¬ 
criptions  of  the  advanced  automation  'functions  of  AERA  1  are 
given  in  "Operational  and  Functional  Description  of  AERA  1.01" 
[33.  . 


The  Sector  Workload  Probe  accesses  various  parts  of  the  AERA 
data  base  as  input,  ftie  sources  for  these  data  are:  Trajec¬ 
tory  Estimation,  Flight  Plan  Conflict  Probe  (FPCP),  and 
Airspace  Probe  (AP).  No  functions  in  AERA  1  depend  upon  the 
outputs  of  the  Sector  Workload  Probe.  However,  later  stages  of 
AERA  may  use  outputs  of  SWP.  The  Conflict  Resolution  function, 
for  example,  may  use  SWP  output  in  the  selection  of  maneuvers 
for  aircraft. 


SWP  Is  unique  among  the  AERA  functions  in  that  its  output  is 
presented  to  the  supervisor.  Other  AERA  functions  either  out¬ 
put  no  information  or  output  information  to  the  (radar) 
controllers. 

1.4. 1.2  En  Route  Sector  Loading 

The  Sector  Workload  Probe  may  interface  with  a  Central  Flow 
Control  (CFC)  function,  En  Route  Sector  Loading  (ELOD),  which 
may  receive  input  data  from  the  SWF.  ELOD,  one  of  the  major 
CFC  enhancements  planned  for  1983  or  early  1984  implementation, 
is  claimed  to  Improve  the  CFC  processes  of  demand  forecasting 
and  prediction  of  en  route  saturation;  these  have  historically 
been  major  weaknesses  of  CFC.  ELOD  determines  areas  of  traffic 
saturation  and  provides  "information"  to  flow  ‘management  in  the 
centers  on  a  predictive  rather  than  reactive  basis.  Its  traf¬ 
fic  demand  projections  are  based  on  Official  Airline  Guide  and 
General  Aviation  schedules,  flight  plans,  manually  entered 
data,  and  arrival  times.  The  flight  plan  or  arrival  times  may 
be  updated  under  certain  conditions.  An  alert  message  is 
generated  if  the  projected  traffic  demand  count  for  any  sector 
or  fix  (specified  point  on  the  aircraft's  route)  during  a 
designated  time-interval  (e.g.,  15  minutes)  exceeds  an  adapted 
threshold  parameter. 

Sector  Workload  Probe  differs  from  En  Route  Sector  Loading  in 
two  major  respects: 

•  SWP  has  access  to  the  full  automation  data  base,  in 
particular,  the  path  of  the  aircraft  through  space  and 
time  (updated  by  radar  reports),  Information  from  FPCP 
and  AP,  and  density  information.  ELOD's  primary  input 
is  flight  plan  information. 

•  SSP  is  a  tool  for  the  supervisor  and  doeB  not  directly 
impact  the  flight  of  any  aircraft.  When  it  indicates 
heavy  workload,  such  as  large  traffic  volume,  the 
supervisor's  response  may  be  to  sectorize  or  alter 
staffing — that  is,  change  the  airspace/ATC  configura- 
tion  but  not  the  traffic  flow  pattern.  When  ELOD 
indicates  heavy  traffic,  no  resolution  is  created  by 
CFC;  however,  the  local  flow  management  may  change  the 
traffic  flow  pattern  but  not  the  airspace/ATC  config¬ 
uration. 

While  the  second  of  the  above  differences  is  fundamental,  the 
first  difference  is  due  primarily  to  ELOD's  early 
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implementation.  ELOD  could  be  enhanced  by  using  the  data 
created  by  SWP  in  the  automation  data  base. 

1.4.2  Role  of  Sector  Workload  Probe  in  Future  System 
-Enhancements  ~~~~~~~~ 

The  role  of  SWP  will  undergo  modifications  in  future  enhance¬ 
ments  of  AERA  as  discussed  below. 

1.4.2 .1  New  Parameters  and  Changes  in  Parameters 

As  various  ATC  operations  are  automated,  the  associated  SWP 
parameters  will  be  determined  and  incorporated  in  the  workload 
measures.  Ongoing  study,  both  before  and  after  implementation 
of  AERA,  may  provide  improved  understanding  of  the  user-system 
interface  Issues  involved,  leading  to  refinements  in  the  SWP 
measures  and  their  associated  parameters.  In  later  stages  of 
AERA  implementation,  when  clearances  are  automatically  deliv¬ 
ered  to  the  aircraft,  the  associated  parameters  will  be 
redefined.  As  new  types  of  planned  actions  are  introduced, 
parameters  may  be  introduced  to  measure  their  contribution  to 
workload. 


1.4. 2. 2  Long  Range  Probe 

The  Long  Range  Probe  function  will  be  Incorporated  into  AERA  1 
to  help  a  controller  decide  whether  to  accept  a  proposed  flight 
plan  or  flight  plan  amendment  (e.g.,  for  a  user  preferred 
route).  Long  Range  Probe  may  be  an  extension  of  Flight  Plan 
Conflict  Probe  and/or  Airspace  Probe.  The  algorithm  and  opera¬ 
tional  use  of  the  Long  Range  Probe  have  not  yet  been  determined. 

The  density  workload  measure  of  SWP  is  different  in  concept 
from  the  Long  Range  Probe  (which  was  originally  called  Density 
Probe).  The  two  functions  serve  different  users  (supervisors 
and  controllers,  respectively).  However,  some  of  Sector  Work¬ 
load  Probe's  measures,  including  the  average  aircraft  count, 
the  overall  workload  measure,  and  the  density  measure,  may 
prove  valuable  sources  of  data  for  use  by  the  Long  Range  Probe. 

1.5  Sector  Workload  Probe  Summary 

This  section  describes  SWP  from  an  operational  point  of  view 
and  gives  an  overview  of  its  internal  functioning. 
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1,5.1  Operational  Description 


The  supervisor  nay  at  any  time  request  an  immediate  display  of 
the  current  and  projected  workload  for  a  specified  sector  or 
set  of  sectors.  The  supervisor  may  also  request  SWP  to  monitor 
selected  sector(s)  for  certain  conditions,  such  as  a  workload 
measure'  exceeding  a  selected  threshold.  Upon  such  a  request, 
SWP  periodically  computes  the  measure(s)  for  the  sector(s)  and 
alerts  the  supervisor  when  these  conditions  are  met. 

The  data  displayed  by  SWP  for  the  sector  or  sectors  specified 
include  average  aircraft  count,  number  of  Flight  Plan  Conflict 
Probe  end  Airspace  Probe  encounters,  and  a  measure  of  actions 
which  are  predicted  to  be  carried  out  by  the  controller.  Each 
measure  is  computed  for  various  times  in  the  hear  future.  In 
addition,  a  measure  of  the  density  information  and  an  overall 
measure  may  be  displayed. 

High  SWP  measures  may  influence  the  supervisor  t.o  increase 
staffing  at  a  sector  or  to  decombine  a  sector,  while  low 
measures  suggest  a  decrease  in  staffing  or  the  combining  of  two 
or  more  sectors  into  one. 

1.5.2  Processing  Overview 

SWP  processing  is  performed  on  data  either  for  'vie  aircraft  or 
for  all  aircraft  in  a  sector.  The  processing  for  one  aircraft 
is  performed  when  the  aircraft's  flight  plan  is  first  entered 
into  the  data  base  or  is  resynchronized  or  otherwise  changed. 
Resynchronization  is  defined  as  the  task  of  recomputing  the 
estimated  trajectory  of  an  aircraft,  when  the  trajectory  is 
inconsistent  with  the  aircrafts'  recent  history  and  the  air¬ 
craft's  last  reported  position.  Trajectories  are  the  modeled 
paths  of  aircraft  through  space  and  time. 

Invocation  of  SWP  occurs  following  automatic  invocation  of 
Plight  Plan  Conflict  Probe  and  Airspace  Probe.  The  SWP  proces¬ 
sing  involves  determining  workload  measures  for  the  aircraft  by 
sector  for  various  times  in  the  future.  Much  of  SWP's  input 
data  1b  output  directly  from  FPCP  and  AP.  Other  SWP  informa¬ 
tion  is  determined  directly  from  the  new/resynchronized 
aircraft’s  trajectory. 

If  Sector  Workload  information  is  requested  directly,  the 
algorithm  immediately  computes  the  data  to  be  displayed  on  all 
aircraft  in  a  sector  or  group  of  sectors.  If  SWP  is  monitoring 
for  a  given  condition,  the  algorithm  computes  and  tests  the 
data  periodically. 
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2.  DEFINITIONS  AND  DESIGN  CONSIDERATIONS 


Section  2  defines  terms  that  will  be  used  in  the  following  sec¬ 
tions  and  lists  design  considerations  that  affect  the  choice  of 
an  algorithm  for  SWP. 

2*1  System  Design  Definitions 

Some  fundamental  terms  which  are  also  used  in  other  AERA  func¬ 
tions  have  already  been  defined  or  discussed  in  Section  1. 
This  section  will  define  terms  which  are  specific  to  SWP. 

2*1.1  Time  Terminology 

The  Sector  Workload  Probe  evaluates  its  workload  measures  only 
up  to  a  certain  time  bound,  called  the  time  horizon,  which  is  a 
system  parameter  whose  value  is  equal  to  the  time  horizon  used 
by  Flight  Plan  Conflict  Probe.  The  common  time  horizon  extends 
far  enough  into  the  future  that  most  trajectories  within  a 
planning  region  are  encompassed  in  their  entireties  (i.e.,  only 
a  few  extend  beyond  the  time  horizon).  For  similar  reasons,  it 
is  advantageous  to  both  FPCP  and  SWP  to  project  trajectory 
information,  as  far  into  the  future  as  possible,  even  though 
neither  SWP  nor  FPCP  has  any  outputs  dependent  on  such  projec¬ 
tions.  The  justification  for  this  is  quite  strong  for  FPCP 
[Vol.  3];  the  justification  in  the  case  of  SWP  is  largely  based 
upon  SWP's  close  interface  with  FPCP. 

Should  a  trajectory  contain  a  portion  that  extends  beyond  the 
time  horizon,  that  portion  is  not  processed  immediately  by  FPCP 
or  SWP.  A  list  is  kept  of  all  such  trajectories  and  is  updated 
whenever  the  trajectories  change.  Periodically,  at  intervals 
of  delta  horizon,  a  determination  is  made  whether  a  portion  of 
any  trajectory  is  now,  with  the  passage  of  time,  encompassed  by 
the  time  horizon.  These  portions  are  treated  like  new  trajec¬ 
tories,  except  that  they  are  stored,  in  the  computer  as 
extensions  of  the  earlier  portions.  Each  such  occurrence  for  a 
new  trajectory  portion  is  called  an  SWP  horizon  update. 

The  SWP  display  time  horizon  is  another  system  parameter  speci- 
fying  the  maximum  time  in  the  future  that  SWP  values  are 
displayed.  It  precedes  the  time  horizon,  by  perhaps  one  and  a 
half  to  two  hours.  The  period  until  the  display  time  horizon 
is  quantized  into  time-intervals  of  equal  length.  This  length, 
another  parameter,  is  called  the  time-interval  duration  and  has 
a  value  of  perhaps  15  minutes.  Workload  measures  are  calcula¬ 
ted  for  these  time-intervals  (but  not  for  any  finer  time 
quantization).  The  time  periods  associated  with  the  time 
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horizon  and  display  time  horizon  must  be  integer  multiples  of 
the  delta  horizon,  which  is,  in  turn,  an  integer  multiple  of 
the  time-interval  duration,  itself  a  multiple  of  the  cell  width 
in  the  time  dimension.  Figure  2-1  illustrates  the  concepts 
developed  in  this  section. 

2.1.2  Sectorization  Schedule 

The  sectorization  plans  consist  of  the  possible  ways  that  basic 
sectors  can  be  combined  via  sectorizations.  The  sectorization 
schedule  identifies  the  current  sectorization  plan  as  well  as 
those  sectorization  plans  (and  their  effective  times)  expected 
to  be  implemented  over  the  interval  between  the  current  time 
and  the  time  horizon. 

2.1.3  SWP  Trajectory  Update 

An  SWP  trajectory  update  is  defined  to  include  any  of  the  fol¬ 
lowing  four  events: 

•  A  trajectory  is  added  to  the  center's  automation  data 
base  for  the  first  time. 

•  A  trajectory  already  in  the  center's  automation  data 
base  is  resynchronized  by  the  Trajectory  Estimation 
Function. 

•  A  trajectory  already  in  the  automation  data  base  is 
altered  due  to  an  action  by  a  ’controller  or  by  another 
AERA  function. 

•  An  SWP  horizon  update  occurs. 

Hereafter,  the  terms  SWP  trajectory  update  and  SWP  horizon  up¬ 
date  will  be  shortened  to  trajectoiy  update  and  horizon  update, 
respectively,  (Note:  FPCP  uses  slightly  different  definitions 
of  these  terms;  the  FPCP  terms  do  not  appear  in  this  volume.) 

Each  trajectory  update  triggers  a  call  to  the  Subject  Aircraft 
Workload  subfunction  of  Sector  Workload  Probe. 

2.1.4  Subject  and  Object  Aircraft 

When  an  aircraft's  trajectory  is  updated,  the  aircraft  is  desig¬ 
nated  as  the  subject.  All  other  aircraft  are  called  objects. 
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2.1.5  Immediate  Mode  and  Conditional  Mode 


When  a  supervisor  requests  to  see  an  immediate  display  of  sector 
workload  information,  SWP  is  said  to  be  in  Immediate  Mode.  The 
request  is  called  an  Immediate  Mode  Request.  If  a  supervisor 
requests  to  see  a  display  of  sector  workload  information  when 
conditions  (specified  by  him  or  her)  are  satisfied,  SWP  is  said 
to  be  in  Conditional  Mode.  The  request  is  then  called  a  Condi¬ 
tional  Mode  Request. 

2.1.6  The  Airspace.  Grids 

SWP  uses  several  grids,  which  have  various  of  the  dimensions 
(x,y,z,t)  to  represent  the  airspace.  The  discrete  compartments 
of  each  grid  are  called  grid  cells  or  cells.  The  grids  and 
their  dimensions  are  the  following: 

•  The  sector  airspace  grid  to  store  sector  boundaries 
(x,yJzT 

•  A  grid  to  ’represent  trajectories  of  aircraft,  computed 
by  Flight  Plan  Conflict  Probe  (x,y,t) 

•  The  cell  density  airspace  grid,  to  compute  a  fine 
measure  of  density  (x,y,z,t) 

•  The  block  density  airspace  grid,  to  compute  a  coarse 
measure  of  density  (x,y,z,t) 

The  first  three  grids  share  common  widths  in  the  x  and  y  dimen¬ 
sions  which  are  doubled  in  size  in  the  fourth  grid.  Each  grid's 
cells  are  squares  in  the  (x,y)  plan.  All  cell  extents  in  the  z 
dimension  (first,  third  and  fourth  grid)  are  equal,  but  the  com¬ 
mon  z  extent  may  vary  with  altitude  above  the  ground.  Cell 
extents  in  the  t  dimension  are  shared  by  the  second  and  third 
grid;  this  extent  is  doubled  in  the  fourth. 

The  sector  airspace  grid  assigns  each  of  its  cells  to  a  single 
basic  sector.  It  is  adapted  to  the  site,  and  is  used  only  as 
input  to  SWP. 

The  second  grid  is  computed  by  Flight  Plan  Conflict  Probe  [Vol. 
3,  Section  2.1].  The  trajectory  of  an  aircraft  traverses  a 
sequence  of  cells.  A  cell  is  said  to  be  occupied  if  the  trajec¬ 
tory  satisfies  certain  FPCP  and  SWP  criteria  with  respect  to 
that  cell.  The  set  of  cells  occupied  by  an  aircraft's  trajec¬ 
tory  Is  called  the  aircraft's  grid  chain.  Holding  patterns  are 
also  included  in  the  grid  chain.  The  grid  chain  computed  by 


FPCP  works  satisfactorily  for  SWP  (assuming  a  common  grid  size 
as  discussed  in  Section  2.2.6).  There  is  no  necessity  for  SWP 
to  redo  the  FPCP  calculations  for  generating  a  grid  chain  given 
an  approximation  of  an  aircraft’s  trajectory. 

The  third  and  fourth  grids  are  used  by  SWP  to  accumulate  counts 
of  the  number  of  aircraft  occupying  each  grid  cell  for  computa¬ 
tion  of  the  density  measure.  For  convenience,  when  these  two 
grids  are  discussed,  the  terms  cell  and  block  are  used  to  refer 
to  cells  in  the  cell  density  airspace'  grid  and  the  block  density 
airspace  airspace  grid,  respectively.  Each  block,  then,  con¬ 
tains  eight  cells.  The  sizes  of  the  x,  y,  and  t  dimensions  of  a 
block  are  twice  those  of  a  cell,  but  the  size  of  the  z  dimension 
of  a  block  is  the  same  as  that  for  a  cell. 

The  extent  of  cells  (and  blocks)  in  the  z  dimension  (used  in  the 
first,  third  and  fourth  grids)  may  take  different  values  with 
different  altitudes  above  the  ground.  The  z  extent  is  small 
enough  to  allow  all  parts  of  each  cell  to  be  within  or  near 
enough  to  its  basic  sector  that  events  within  the  cell  contri¬ 
bute  to  workload  for  that  basic  sector.  Values  for  the  cell 
size  in  z  above  6000  feet  appear  incompatible  with  this  con¬ 
straint..  On  the  other  hand,  the  values  of  cell  size  in  z  must 
be  large  enough  to  have  a  good  probability  of  grouping  aircraft 
together  which  are  close  enough  in  altitude  over  the  time  hori¬ 
zon  Interval,  so  that  their  interaction  is  included  as  a 
contribution  to  workload.  The  time  horizon  is  far  enough  in  the 
future  that  values  of  cell  size  in  z  below  3000  feet  appear 
inconsistent  with  this  constraint.  Other  factors  that  may 
affect  the  selection  of  cell  size  in  the  z  dimension  are  the 
locations  of  flight  level  boundaries  and  the  altitudes  most  com¬ 
monly  used  to  divide  sectors  along  the  vertical  axis. 

2.1.7  Nominees  and  Encounters 


In  Flight  Plan  Conflict  Probe,  an  object-  aircraft  is  called  a 
nominee  if  it  and  the  subject  aircraft  (a)  occupy  the  same  grid 
cell  or.  adjacent  cells  and  (b)  are  separated  vertically  by  less 
than  a  vertical  separtion  criterion.  All  nominees  are  tested 
for  horizontal  separation  with  the  subject  aircraft.  If  separa¬ 
tion  is  predicted  to  fall  below  a  certain  specified  threshold 
referred  to  in  Vol.  3  as  advisory  Seph),  then  the  nominee  is 
called  an  encounter. 

Analogously,  in  Airspace  Probe,  an  object  (in  this  case  a  poly¬ 
gon  of  airspace)  is  also  called  a  nominee  if  it  and  the  subject 
aircraft  trajectory  occupy  the  same  grid  cell  or  adjacent 
cells.  The  nominees  are  tested  for  horizontal  separation  with 
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certain  restricted  or  warning  airspaces  in  the  planning  region. 
If  this  separation  falls  below  a  threshold,  the  nominee  is  then 
called  an  encounter. 

The  numbers  of  FPCP  and  AP  encounters  are  useful  indicators  of 
sector  workload. 

2.1.8  Planned  Actions 


A  planned  action  for  an  aircraft  is  any  one  of  a  set  of  actions 
that  can  be  anticipated.  The  workload  of  a  planned  action  is 
expected  to  be  performed  for  the  aircraft  at  some  time  t,  called 
the  activation  time  (an  input  to  SWP).  Planned  actions  are  out¬ 
put  by  various  AERA  functions.  Activation  times  are  computed 
from  data  associated  with  the  planned  actions.  Planned  actions 
are  used  internally  in  AERA  1;  they  are  not,  like  encounters, 
intended  to  be  warnings  to  the  controller.  In  AERA  1  the 
planned  actions  consist  of  vectors,  altitude  changes,  altitude 
changes  with  restrictions,  speed  changes, and  holding  patterns. 

2.1.9  Workload 


Workload  is  defined  to  be  those  tasks  performed  to  provide  air 
traffic  control  services.  References  to  workload  in  this  docu¬ 
ment  are  associated  with  sector  workload  as  opposed  to 
controller  workload.  Sector  workload  includes  those  tasks  per¬ 
formed  in  a  sector,  while  controller  workload  consists  of  the 
actual  work  performed  by  controllers  at  the  control  positions. 
Sector  workload  is  easier  to  measure  than  controller  workload 
because  controller  workload  is  dependent  on  human  factors,  i.e., 
variability  in  the  types  of  ATC  methods  among  controllers,  user- 
system  interactions  and  the  number  of  controllers  assigned  to  a 
sector. 

Workload  measures  may  be  expressed  as  weighted  sums  of  sub¬ 
measures,  which  are  defined  as  the  -finest  subdivision  of 
workload  that  is  calculated.  For  example,  the  planned  action 
measure  has  a  submeasure  for  each  type  of  planned  action. 

2.2  System  Design  Considerations 

This  section  discusses  the  design  considerations  that  must  be 
taken  into  account  while  designing  algorithms  for  SWP. 

2.2.1  No  Background  Knowledge  Required  of  User 

The  supervisor  should  be  able  to  use  the  SWP  measures  without 
detailed  knowledge  of  the  algorithm  that  generates  them. 


2-6 


A  very  high-level  understanding  of  the  algorithm  may  be  useful, 
however.  The  supervisor  may  receive  instruction  on  how  to 
interact  and  utilize  the  features  of  the  output  options  and  the 
workload  measures. 

2.2.2  Display  Considerations 

This  specification  does  not  address  the  formats  that  may  be  used 
to  display  SWP  data,  nor  the  manner  in  which  a  supervisor  may 
input  a  request  for  SWP  activation.  It  is  assumed  that  the  dis¬ 
play  is  flexible  and  easy  to  use  (perhaps  menu  driven),  has  some 
standard  editing  capability,  and  can  satisfy  both  the  supervisor 
who  wishes  to  explore  every  feature  as  well  as  the  supervisor 
who  wishes  to  minimize  the  time  required  to  learn  how  the  func¬ 
tion  is  used. 

2.2.3  Limitations  of  Sector  Workload  Probe 


SWP  makes  no  attempt  to  measure  workload  directly  in  terms  of 
staff-hours.  Such  a  measurement  would  be  Impossible  and  mis¬ 
leading  to  the  supervisor,  given  the  limited  data  available  to 
AERA.  Even  with  full  (and  time  consuming)  cooperation  on  the 
part  of  the  controller,  it  is  not  possible  to  divide  the  process 
of  decision-making  into  time-measured  portions  divided  among 
various  tasks. 

SWP  has  no  knowledge  of  current  staffing  levels  or  of  individual 
capabilities  of  controllers.  The  SWP  may  be  more  useful  to  the 
supervisor  if  the  supervisor  sets  the  thresholds  to  reflect  this 
information. 

The  Sector  Workload  Probe  is  not  intended  to  be  used  by  control¬ 
lers  (e.g.,  for  determining  whether  an  individual  aircraft  may 
be  granted  a  change  in  flight  plan).  As  a  tool  for  the  super¬ 
visor,  SWP  doeB  not  itself  make  suggestions  concerning 
management  matters  (such  as  the  amount  of -staffing),  but  it  does 
provide  information  to  support  such  decisions. 

2.2.4  Workload  Allocated  by  Place  and  Time 

Each  event  (such  as  an  encounter  or  a  planned  action)  that  con¬ 
tributes  to  a  workload  measure  is  allocated  to  a  specific  place 
and  time:  the  basic  sector  in  which  it  occurs  and  the  time- 
interval  (Section  2.1.1)  in  which  it  is  contained. 
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2.2.5  Encounters,  Planned  Actions,  Display  Times,  and 
Sector  Workload 

Consider  an  encounter  pair  for  which  the  FPCP  horizontal  and 
vertical  separation  criteria  are  predicted  to  be  first  violated 
at  time  t.  It  is  inappropriate  to  assign  the  workload  involved 
in  resolving  the  encounter  at  time  t  to  the  (basic)  sector(s) 
the  aircraft  occupy  at  time  t,  since  the  role  of  FPCP  is  to 
alert  the  controller  long  enough  in  advance  of  a  separation 
violation  to  allow  him  to  resolve  the  conflict  routinely. 
Therefore,  the  workload  is  assigned  to  the  sector  which  receives 
the  advisory  message  from  FPCP  and  to  the  time  this  message  is 
displayed.  This  time  is  called  the  encounter's  display-as- 
advisory  time,  and  is  input  to  SWP  for  each  encounter.  Figure 
2-2  shows  the  interrelation  between  this  time  and  the  time  of 
violation  of  horizontal  separation  criterion.  Figure  2-3  shows 
how  the  workload  may  be  allocated  to  sectors  based  on  encounter 
display-as-advisory  times. 

For  an  Airspace  Probe  encounter,  the  workload  (although 
different  from  that  for  an  FPCP  encounter)  is  likewise  ass?  -ned 
to  the  time-interval  containing  the  display  time  and  to  the  sec  • 
tor  which  receives  the  message  of  an  AP  encounter. 

Similar  timing  considerations  apply  as  well  to  the  workload 
measure  based  on  the  planned  actions.  AERA  accounts  for  con¬ 
troller  (and  pilot  and  aircraft)  reaction  time  by  modeling 
aircraft  conformance  to  lag  the  activation  time.  The  controller 
is  expected  to  have  thought  about  the  planned  action  prior  to 
the  activation  time  and  to  communicate  the  clearance  for  the 
planned  action  following  that  time.  It  is  possible  to  imagine 
cases  where  the  controller's  think  time  exceeds  or  is  exceeded 
by  his  performance  time.  Such  considerations  go  beyond  the 
scope  of  this  specification.  The  workload  is  simply  assigned  to 
the  time  interval  containing  the  activation  time  and  to  the 
(basic)  sector  then  occupied  by  the  aircraft. 

2.2.6  Interface  Between  FPCP  and  SWP 

This  specification  assumes  that  SWP  and  FPCP  use  airspace  grids 
with  the  same  cell  sizes  in  the  x,  y,  and  t  dimensions.  This 
assumption  may  allow  savings  in  computer  storage  and  execution 
time.  The  width  of  the  grid  cells  in  the  horizontal  and  time 
dimensions  are  system  parameters.  There  are  certain  implica¬ 
tions  in  setting  them  equal  for  the  two  functions. 

The  exact  horizontal  dimensions  of  the  grid  cells  are,  within 
broad  limits,  not  critical  to  SWP.  They  are  critical  to  FPCP 
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POSSIBLE  ASSIGNMENT  OF  WORKLOAD  FOR  FPCP  ENCOUNTER 


and  depend-  on  the  exact  value  of  the  advisory  horizontal  separa¬ 
tion  criterion  [Vol.  3,  Section  2.1.10]  which  is  still  to  be 
determined  but  is  expected  to  fall  within  SWP’s  broad  limits. 
On  the  other  hand,  the  exact  dimensions  of  the  grid  cells  in  the 
time  dimension  are,  within  broad  limits,  not  critical  to  FPCP 
but  are  critical  to  SWP:  their  time  extent  multiplied  by  2n 
must  equal  the  time-interval  duration,  for  some  positive  integer 
n.  Should  further  study  prove  that  the  optimal  range  of  the 
grid  cell's  time  extent  for  FPCP  does  not  contain  SWP's  time- 
interval  duration  divided  by  2n,  gfid-size-commonality  implies 
that  the  cell's  time  extent  must  be  rounded  up  to  that  value,  at 
the  cost  of  more  nominees  and  more  calls  to  the  FPCP  Fine  Fil¬ 
ter.  There  are  certain  advantages,  however,  even  apart  from  SWP 
considerations,  for  the  FPCP  grid  to  be  divided  (such  as  SWP’s 
time-intervals)  on  the  time  dimension  in  natural  clock  incre¬ 
ments,  even  if  these  are  not  quite  optimal  in  reducing 
nominees.  For  Instance,  for  a  trial  FPCP  probe,  the  controller 
might  want  a  list  of  all  encounters  with  display-as-advisory 
times  earlier  than  3:00  p.m. 

The  costs  associated'  with  assuming  common  grids  for  both  SWP  and 
FPCP  appear  to  be  outweighed  by  the  benefits.  It  is  worth 
noting,  however,  in  view  of  the  fact  that  SWP  and  FPCP  system 
parameter  values  have  yet  to  be  determined,  that  different  grid 
sizes  could  be  used  for  SWP  and  FPCP  without  substantial  changes 
in  either  algorithm.  In  this  case,  all  references  in  this 
volume  to  the  airspace  grid  cells  created  by  FPCP  would  apply  to 
corresponding  data  created  by  SWP.  The  FPCP  Grid  Chain  Genera¬ 
tor  [Vol.  3,  Section  4.1]  would  simply  be  run  twice,  once  for 
each  grid. 

2.2.7  Access  to  Sector  Workload  Probe  Information 


SWP  information  may  be  obtained  for  an  area  or  for  a  set  of 
basic  sectors.  Supervisors  may  access  data  on  other  areas  as 
well  as  their  own. 

Access  to  SWP  information  is  not  limited  to  the  supervisor's  own 
area.  Data  for  any  sector  in  the  center  are  available  for 
access.  Information  on  workload  in  adjacent  sectors  may  be  use¬ 
ful  in  helping  a  supervisor  evaluate  factors  including  the 
following: 

•  Whether  the  supervisor's  own  controllers  should 
alleviate  their  workload  by  routing  aircraft  through 
the  adjacent  sectors 
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•  Whether  there  is  a  likelihood  of  an  adjacent  sector’s 
personnel  alleviating  heavy  workload  by  routing  air¬ 
craft  through  the  supervisor's  area 

•  Whether  coordination  is  necessary  with  adjacent  flow 
control  facilities  or  with  Central  Flow  Control 

It  is  not  expected  that  controllers  (nonsupervisors)  will  use 
SWP  data,  although  no  reasons  have  been  identified  to  withhold 
this  information  should  a  controller  request  it. 

2.2.8  Events  at  Sectorization 


SWF  is  not  explicitly  intended  to  be  used  on  a  trial  basis  to 
determine  what  workload  values  would  occur  under  a  sectorization 
plan  not  currently  in  effect.  The  SWP  thus  differs  in  this 
respect  from  the  other  AERA  1  probes  (Airspace  Probe  and  FPCP), 
which  are  intended  to  allow  trial  probes  of  proposed  flight 
plans.  A  supervisor  should,  however,  as  a  part  of  a  normal 
error-recovery  process,  be  able  to  input  and  verify  any  sectori¬ 
zation  plan  before  committing  the  system  to  it.  The  results  of 
a  trial  sectorization  plan  (before  commitment)  should  be  avail¬ 
able  only  to  the  supervisor  initiating  such  a  plan. 

2.2.9  Adaptation  of  Workload  Measures 

Multiplicative  constants  called  adaptation  factors  may  be 
applied  to  the  displayed  workload  measures  to  account  for  the 
decreasing  quality  and  quantity  of  data  and  the  increasing 
chance  of  data  modification  by  resynchronization  with  increasing 
prediction  times.  The  adaptation  factors  were  created  offline 
based  on  the  historical  data  on  the  predicted  versus  the 
observed  SWP  workload  measures  and  overall  measures.  The  adap¬ 
tation  factors  may  depend  on  the  sector,  season  of  the  year,  day 
of  the  week,  time  of  day,  and  how  far  ahead  the  prediction  is 
made. 

The  adaptation  factors  are  determined  for  each  workload  measure 
and  for  various  values  of  v  (number  of  time-intervals)  and  t 
(time  at  which  SWP  is  invoked)  from  the  following: 

1.  Predicted  historical  expected  value  of  the  workload 
measure  at  time  t,  projected  v  time-intervals  into  the 
future  (e.g.,  the  average  workload  calculated  at  8  PM 
for  9  PM  on  Sundays  in  Jul>  for  Sector  5) 
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2.  Observed  historical  value  of  the  workload  measure  v 
time-intervals  after  time  t  (e.g.,  the  average  workload 
calculated  at  9  PM  for  9  PM  on  Sundays  in  July  for  Sec¬ 
tor  5) 

3.  Predicted  current  value  of  the  workload  measure  at  time 
t,  projected  v  time-intervals  into  the  future  (e.g., 
the  workload  calculated  at  8  PM  for  9  PM  on  a  parti¬ 
cular  Sunday  in  July  for  Sector  5) 

The  first  two  values  are  SWP  constants  (for  various  values  of 
v,  t,  season,  day  of  week,  etc.)  but  the  third  value  is  cal¬ 
culated  on-line.  From  these  three  values,  the  adaptation  factor 
is  calculated  for  that  sector  for  a  particular  choice  of  v  and 
t.  For  instance,  as  a  rush  hour'  builds,  workload  predictions 
based  on  trajectory  data  may  be  underestimates,  causing  the 
values  of  adaptation  factors  to  be  greater  than  one.  As  the 
rush  hour  diminishes,  predictions  may  be  overestimates,  causing 
the  values  of  the  adaptation  factors  to  be  less  than  one. 


3.  SECTOR  WORKLOAD  PROBE  FUNCTIONAL  DESIGN 


SWP  is  divided  into  two  subfunctions:  Subject  Aircraft  Work¬ 
load  and  Supervisor  Requests. 

3 .1  Environment 


This  section  describes  input  data  required  by  the  SWP  algo¬ 
rithm,  conditions  causing  activation  of  the  algorithm,  and  out¬ 
put  data  produced. 

3.1.1  Input  Data  and  Activation 

3.1. 1.1  Input  Data 

The  input  data  for  the  Sector  Workload  Probe  are  global  data 
and  may  be  outlined  as  follows: 

•  Output  from  other  AERA  Functions 

-  FPCP  grid  chain 

-  AP  encounter  data 

-  FPCP  encounter  data 

—  Before-  trajectory  update 
—  After  trajectory  update 

-  Planned  action  data 

•  Site-specific  data 

-  Sectorizatlon  plans 

-  Sectorizatlon  schedule 

-  Adaptation  factors 

-  Geographic  extent  of  basic  sectors  (the  sector 
airspace  grid) 

•  Parameters 

-  Subject  aircraft  identity 

-  Time-interval  duration 

-  Time  horizon 

-  Display  time  horizon 

-  Weighting  coefficients 

-  Frequency-of-testing  parameter 

-  AP  encounter  notification  time  parameter 

•  Supervisor  requests 

-  Sector (s)  to  display  outputs 

-  Time-interval(s)  to  evaluate 

-  Condition(s)  to  test  (specify  sector  number, 
workload  measures  and  threshold  values) 

-  Display  editing  features 
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3. 1.1. 2  Automatic  Activation  Sequences 


Hie  Subject  Aircraft  Workload  Subfunction  Is  automatically 
activated  by  any  trajectory  update  for  an  aircraft  in  the  auto¬ 
mation  data  base.  During  Conditional  Mode,  the  Workload 
Evaluation  Component  of  the  Supervisor  Requests  Subfunction  is 
automatically  activated  on  a  periodic  basis. 

3. 1.1. 3  Supervisor  Initiating  Sequences 

The  Supervisor  Request  Subfunction  is  initiated  by  the  super¬ 
visor  by  an  Immediate  Mode  Request,  a  Conditional  Mode  Request, 
or  a  request  to  edit  the  display. 

3.1.2  Output  Data 

3. 1.2.1  Output  to  the  Global  Data  Base 

SWP  outputs  to  the  global  data  base  are  used  by  the  display 
function,  but  not  by  any  other  AERA  1.01  function.  (In  the 
future,  outputs  may  be  used  by  ELOD  or  other  AERA  functions  as 
discussed  in  Section  1.4. 1.1  and  1.4. 1.2).  The  outputs  are  in 
the  form  of  tables.  The  global  data  base  receives  two  types  of 
outputs  from  SWP,  as  described  below.  Both  refer  to  aggregate 
aircraft  data  (i.e.,  data  computed  for  each  aircraft  and  then 
summed  over  all  aircraft). 

The  first  type  of  output  consists  of  a  table  for  the  aggregate 
aircraft  in  each  basic  sector  called  the  BASIC  SECTOR  WORKLOAD 
MEASURES  (BSWM)  Table.  Table  3-1  presents  one  method  of  organ¬ 
isation  for  the  data.  The  BSWM  Table  is  updated  with  each 
trajectory  update.  The  table  includes  a  record  for  each  pair 
of  basic  sectors  and  time-intervals  from  the  present  to  the 
time  horizon. 

The  fields  include  the  following: 

•  Total  flight  time 

•  Total  FPCP  encounter  count 

•  Total  AP  encounter  count 

•  Total  count  on  planned  actions  for  each  type  of  planned 
action 

•  Average  aircraft  count 

•  Weighted  sum  of  the  planned  actions 

•  Density  measure 

•  Overall  measure 
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The  second  type  of  output  consists  of  a  table  for  the  aggregate 
aircraft  in  each  combined  sector  in  an  area.  This  table  is 
known  as  the  COMBINED  SECTOR  WORKLOAD  MEASURES  (CSWM)  Table. 
The  data  for  this  table  are  computed  when  tKi  workload  Is 
evaluated  for  the  requested  area.  The  COMBINED_SECTOR_ 
WORKLOAD__MEASURES  Table  contains  the  same  types  of  information 
as  the  BASIC_SECTOR_WORKLQAD_MEASURES  Table,  as  well  as  three 
additional  fields  for  the  density  measure. 

3. 1.2. 2  Output  to  the  Supervisor 

The  output  to  the  supervisor  consists  of  a  subset  of  the  fol¬ 
lowing  workload  measures  displayed  for  the  organization  type 
and  time-intervals  specified.  ,  If  the  organization  type  is  an 
area,  then  the  outputs  are  subsets  of  the  COMBINED_SECTOR_ 
WORKLOAD_MEASURES  (CSWM)  Table.  If  the  organization  type  is 
sectors,  then  the  outputs  are  subsets  of  the  BASIC_SECTOR_ 
W ORKLOAD_MEASURES  (BSWM)  Table.  These  outputs  include  the: 

•  Average  aircraft  count 

•  Number  of  encounters  for  both  (FPCP  and  AP) 

•  Weighted  sum  of  the  planned  actions 

•  Density  measure 

•  Overall  measure  (a  weighted  sum  of  the  above  outputs) 

The  number  of  each  type  of  planned  action  may,  upon  supervisor 
request,  be  displayed.  Also  the  values  may  be  displayed  for 
the  measures  adjusted  by  the  adaptation  factors. 

3.2  Design  Assumptions 

The  design  of  the  SWP  algorithm  is  based  on  the  assumptions 
discussed  below. 

3.2.1  Considerations  Regarding  Conditional  Mode  and  Immediate 
Mode 

In  Conditional  Mode,  the  supervisor  must  specify  each  condition 
to  be  monitored:  the  sector(B)  and  workload  measure(s)  to 
test,  and  the  threshold(s)  to  test  against.  AERA  provides  no 
default  thresholds  for  Conditional  Mode. 

The  supervisor  may  make  Immediate  Mode  Requests  during  Condi¬ 
tional  Mode  without  affecting  Conditional  Mode.  The  supervisor 
may  cancel  Conditional  Mode  or  modify  at  any  time  the  condi¬ 
tions  specified. 
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3.2.2  Sectorization 


Several  design  assumptions  are  made  for  the  capability  of  veri¬ 
fying  a  new  sectorization  plan  or  a  trial  SWP.  A  trial  SWP  is 
initiated  by  the  supervisor  as  an  Immediate  Mode  Request.  The 
outputs  for  a  trial  sectorization  plan  will  be  based  on  the 
combined  sectors  i”  the  specified  area  instead  of  the  basic 
sectors,  which  would  not  be  affected  by  a  change  in  the  sector¬ 
ization  schedule.  The  main  distinction  between  a  trial  SWP  and 
a  normal  request  for  a  workload  evaluation  of  an  area  is  that  a 
different  sectorization  schedule  is  accessed  (see  Section 
2.2.8). 

3.3  Subfunctions  of  Sector  Workload  Probe 


There  are  two  subfunctions  in  the  SWP  algorithm:  the  Subject 
Aircraft  Workload  subfunction  and  the  Supervisor  Requests  sub¬ 
function.  This  section  gives  an  overview  of  these  subfunctions 
and  discusses  changes  that  may  be  appropriate  as  later  phases 
of  AERA  are  introduced. 

3.3.1  Subject  Aircraft  Workload 

When  a  trajectory  update  occurs,  the  Subject  Aircraft  Workload 
Subfunction  updates  the  workload  data  on  the  subject  aircraft. 
Points  on  the  trajectory  where  the  aircraft  enters  either  a  new 
sector  or  a  new  time-interval  are  identified.  These  points 
subdivide  the  trajectory  into  portions  called  sector-time- 
intervals.  All  workload  occurring  within  a  sector-time- 
interval  is  treated  as  a  unit.  The  values  for  each  workload 
submeasure  in  each  sector-time-interval  are  calculated  and 
stored  for  the  subject.  The  values  for  the  aggregate  air¬ 
craft  (in  the  Basic  Sector  Workload  Measures  Table)  are  updated 
according  to  the  net  change  due  to  the  trajectory  update. 

3.3.2  Supervisor  Requests 

The  Supervisor  Requests  Subfunction  receives  and  processes 
various  data  entered  by  the  supervisor.  To  evaluate  and  dis¬ 
play  the  workload  values  for  a  specified  sector  (an  Immediate 
Mode  Request),  the  subfunction  uses  the  data  on  aggregate 
aircraft.  The  workload  submeasures  .  in  the  BASIC_SECTOR_ 
WORKLOAD_MEASURES  Table  are  summed  for  each  time-interval  over 
each  basic  sector  comprising  the  combined  sector.  The  overall 
measure  for  each  time-interval  (weighted  sum  of  the  FPCP 
encounter  count,  the  AP  encounter  count,  the  planned  actions, 
and  the  density  measures)  is  computed.  The  Supervisor  Requests 
Subfunction  also  processes  Conditional  Mode  Requests  by  the 
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supervisor  and  handles  editing  of  display  features  for  the 
table  formats  and  other  console  options. 

3.4  Expandability 

As  the  development  of  AERA  continues,  as  described  in  "Opera¬ 
tional  and  Functional  Description  of  the  AERA  Packages"  [5], 
some  enhancements  will  be  necessary  for  the  Sector  Workload 
Probe.  Ihe  values  of  the  weighting  coefficients  for  the  auto¬ 
mated  activities  (such  as  planned  actions)  may  decrease  as 
automation  proceeds  towards  automatic  decision  making  and 
clearance  delivery.  For  those  planned  actions  not  implemented 
in  AERA  1.01,  the  values  of  the  weighting  coefficients  are 
included  as  the  planned  actions  are  implemented.  Eventually, 
automation  will  play  a  predominant  role  in  controlling  routine 
traffic,  with  the  controller  monitoring  the  system  and  handling 
exception  conditions.  There  may  then  be  a  need  to  reevaluate 
the  Sector  Workload  Probe  algorithm,  since  the  factors  affec¬ 
ting  workload  may  be  different. 

Some  expandability  may  occur  in  user-system  interfaces  for 
SWP.  A  supervisor,  such  as  the  Area  Manager,  may  desire  to 
view  the  outputs  of  several  areas  at  the  same  time.  The  super¬ 
visors  may  specify  the  display  features  that  they  desire  for 
initialization  of  the  displayed  output  options  when  they  are 
using  SWP. 


DETAILED  DESCRIPTION 


The  Subject  Aircraft  Workload  and  Supervisor  Requests  subfunc¬ 
tions  are  activated  under  different  circumstances.  The 
activation  of  the  first  oubfimction  is  automatic  and  is  ini¬ 
tiated  by  a  trajectory  update.  A  supervisor  may  activate  the 
second  by  direct  request.  The  Subject  Aircraft  Workload  sub¬ 
function  calculates  an  aircraft's  contribution  to  workload 
according  to  the  workload  measures.  The  Supervisor  Requests 
subfunction  processes  various  requests  from  the  supervisor  and 
displays  the  outputs  in  the  format  he  or  she  has  defined. 

4.1  Subject  Aircraft  Workload  Subfunction 

The  Subject  Aircraft  Workload  subfunction  is  invoked  automatic¬ 
ally  with  the  occurrence  of  a  trajectory  update,  following 
invocation  of  the  Flight  Plan  Conflict  Probe. 

The  values  of  several  variables  or  parameters  are  required  as 
inputs  in  order  that  the  Subject  Aircraft  Workload  subfunction 
can  set  the  values  of  the  corresponding  shared  local  parameters: 

•  Subject  flight  identifier  (Sflid) 

•  Status  of  the  trajectory  update  (Trajectory _Update_ 
Status) 

•  AP  notification  duration  (AP_Not_Dur) 

The  AP_Not_Dur  is  the  time  duration  between  the  time  the  con¬ 
troller  is  given  a  message  of  the  AP  encounter  (immediately 
after  the  encounter  is  determined)  and  the  time  of  penetration 
of  the  airspace  by  the  aircraft. 

Also,  the  Initialization  of  several  input  tables  is  required 
prior  to  invocation  of  the  Subject  Aircraft  Workload  subfunc¬ 
tion.  These  tables  are  the  following: 

•  Sector  airspace  grid  (SWPjCELL) 

Cell  density  airspace  grid  (CELLJDENSITY) 

•  Block  density  airspace  grid  (BLOCK_DENSITY) 

•  BASIC_SECTOR_WORKLQAD_HEASURES 

Since  the  data  in  the  sector  airspace  grid  are  created  by  cen¬ 
ter  personnel  and  updated  infrequently,  the  data  are  stored  for 
access  by  SWPu  When  the  automation  data  base  is  initialized, 
the  cell  density  airspace  grid  and  the  block  density  airspace 
grid  are  created  with  zeroes  for  the  values  of  aircraft  count. 
Maintenance  of  these  tables  is  required  to  remove  those  records 
in  the  tables  for  which  the  time  values  are  no  longer  current 
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and  to  add  records  for  future  time  values  not  in  the  table. 
These  operations  are  not  discussed  in  this  volume. 

When  the  automation  data  bases  is  initialized,  the  BASIC_SECTOR_ 
WORKLQAD_MEASURES  Table  is  created  with  the  basic  sectors  and 
the  time  intervals  designated  but  with  values  of  zero  for  the 
other  fields.  Maintenance  of  these  records  is  also  needed  to 
update  the  time  intervals.  No  outputs  of  this  subfunction  are 
directly  intended  for  operational,  use.  However,  the  outputs 
INDIVIDUA1_AIRCRAFT_W0RKL0AD  (IAW)  Table,  BASIC_SECTOR_ 
WORKLQAD_MEASURES  Table,  cell  density  airspace  grid  data 
(CELL_DENSITY)  and  block  density  airspace  grid  data  (BL0CK_ 
DENSITY)  are  used  by  the  Supervisor  Requests  subfunction  to 
produce  outputs  for  operational,  use. 

Two  components  make  up  this  subfunction  and  they  are  processed 
in  the  following  order: 

•  Individual  Aircraft  Workload  Update 

•  Basic  Sector  Workload  Update 

Figure  4-1  shows  the  structure  of  the  components  for  the  Sub¬ 
ject  Aircraft  Workload  subfunction. 

4.1.1  Individual  Aircraft  Workload  Update  Component 

4. 1.1.1  Mission 


For  each  aircraft,  SWP  maintains  records  in  a  table  called  the 
INDIVIDUAL  AIRCRAFT  WORKLOAD  (IAW)  Table.  Table  4-1  illus¬ 
trates  some  typical  IAW  data.  The  IAW  table  includes  a  record 
for  each  of  an  aircraft’s  sector-time-intervals,  according  to 
the  aircraft's  latest  trajectory  update.  Each  pair  and  its 
record  corresponds  to  a  sector-time-interval  (Section  3.3*1) . 

The  IAW  table  contains  a  field  for  each’ of  the  following ; 

•  Sector  number 

•  Time  interval  identifier 

•  Beginning  time  in  the  sector-time-interval 

•  Ending  time  in  the  sector-time-lnterval 

•  Total  flight  time 

•  FPCP  encounter  count 

•  AP  encounter  count 

•  Count  of  planned  actions  for  each  planned  action  type 
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Section  4.1.1  Section  4.1.2 


FIGURE  4-1 

SUBJECT  AIRCRAFT  WORKLOAD  SUBFUNCTION 
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TABLE  4-1 

LE  OF  INDIVIDUAL_AIRCRAFT_WORKLOAD  TABLE 


The  Individual  Aircraft  Workload  Update  component  creates  a 
local  table  called  the  REVISED  SUBJECT  WORKLOAD  (RSW)  Table  for 
the  subject.  The  fields  of  this  table  are  identical  to  those 
of  the  INDIVIDUAL_AIRCRAFT_WORKLOAD  (IAW)  Table.  The  RSW  Table 
stores  workload  information  for  the  subject  according  to  the 
current  trajectory  update;  the  IAW  Table  contains,  when  this 
component  is  invoked,  workload  information  for  the  subject 
according  to  its  previous  trajectory  update,  if  any. 

This  component  also  updates  the  IAW  Table  for  certain  object 
aircraft— those  for  which  the  FPCP  encounter  Information  has 
changed  due  to  the  trajectory  update.  These  aircraft  are 
called  encounter-status-changed  or  ESC  aircraft.  There  are 
three  reasons  the  encounter  status' may  change: 

•  An  encounter  has  become  a  non-encounter. 

•  A  non-encounter  has  become  an  encounter. 

•  A  previous  encounter  has  remained,  but  its  display-as- 
advisory  time  has  changed,  with  a  possible  associated 
change  in  basic  sectors. 

One  example  of  the  third  type  (as  shown  in  Figure  4-2)  is  a 
^synchronization  of  the  subject  which  changes  the  sector  and 
timer interval  of  the  ESC  aircraft’s  display-as-advisory  time. 

4. 1.1. 2  Design  Consideration  and  Component  Environment 

Input 

The  primary  inputs  are  the  trajectory  update  and  the  IAW 
Table.  Other  inputs  include  the  following: 

•  SWP  Parameters 

-  Time-interval  duration  (Time_Interval_Duration) 

-  Time  horizon  (Time_Horizon) 

—  AP  encounter  notification  time  parameter 
(AP_Not_Dur) 

•  AERA  Global  Data  Base 

-  FPCP  encounters  (ENCOUNTERS  and  PRIOR  ENCOUNTERS) 

-  AP  encounters  (ENVIRONMENTALjCONFLICTj 

-  Planned  actions  (PLANNED  ACTIONS  and  PLANNED 
ACTIONJHJRATION) 

-  Grid  chain  for  subject  (SPARSEjCELLS) 
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-  Sectorization  schedule  (SECTORIZmON_SCHEDULE) 

-  Sectorization  plans  (SECTORIZATION_PLAN) 

•  Subject  Aircraft  Identity  (Sflid) 

•  Status  of  Trajectory  Update  (Trajectory_Update_Status) 

•  Cell  density  airspace  grid  data  for  all  aircraft  (CELL_ 
DENSITY) 

•  Block  density  airspace  grid  data  for  .all  aircraft 
(BLOCK_DENSITY) 

•  Cell  density  airspace  grid  data  by  subject  (SUBJECT_ 
CELL) 

•  Block  density  airspace  gird  data  by  subject  (SUBJECT^ 
BLOCK) 

Output 

The  outputs  of  the  Individual  Aircraft  Workload  Update  com- 
ponent  are  the  REVISED_SUBJECT_WORKLQAD  (RSW)  Table  for  the 
subject  aircraft,  the  INDIVIDUAL_AIRCRAFT_WORKLOAD  Table,  and 
the  ESC  Tables.  The  ESC  Tables  contain  the  sector-time- 
intervals  (with  FPCP  encounters)  (a)  created  and  (b)  deleted 
from  the  IAW  Table  due  to  changes  in  encounter  display-as- 
advisory  times  for  the  ESC  objects  identified  by  the  trajectory 
update.  The  tables  consist  of  the  ESCJENCREMENT  Table  and  the 
ESG_DECREMENT  Table,  respectively.  The  ESC  Tables  and  the  RSW 
Table  are  shared  local  and  serve  only  as  inputs  to  the  next 
component  (Basic  Sector  Workload  Update).  The  RSW  Table  is 
eventually  copied  into  the  IAW  Table. 

For  each  sector-time-interval  (record)  in  the  IAW  (and  RSW) 
Table,  the  following  information  (fields)  is  recorded: 

•  Time-interval  identifier 

•  Sector  number 

•  Beginning  time  (in  this  sector-time-interval) 

•  Ending  time  (in  this  sector-time-interval) 

•  Total  flight  time  (ending  time  minus . beginning  time) 

•  Number  of  AP  encounters 

•  Number  of  FPCP  encounters 

•  Number  of  each  planned  action  type 
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4 »1.1.3  Component  Design  Logic 


The  Individual  Aircraft  Workload  Update  component  consists  of 
the  following  elements  which  are  called  in  sequence  as  outlined 
in  Figure  4-3: 

Create  Subject  Sector  Time  Interval 
Calculate  Subject  Density 
Calculate  Sector 

Determine  Unique  Sector  Time  Intervals 
Include  Subject  Encounters 
include  Object  Encounters 
Include  Subject  Planned  Actions 

If  the  trajectory  has  been  revised,  then  the  former  density 
data  for  the  subject  (on  the  cell  and  block  levels)  are  removed 
from  the  airspace  density  grids  for  all  aircraft.  The  aircraft 
count  data  for  the  subject  in  the  airspace  density  grids  are 
Initialized  to  zero.  First  the  sector-time-intervals  are 
created  and  entered  in  the  RSW  Table.  Then  the  encounters 
detected  by  FPCP  and  AP  are  counted  in  the  appropriate  sector- 
time-intervals  of  the  RSW  Table.  The  FPCP  encounters  are 
likewise  included  in  the  appropriate  records  of  the  IAW  Table 
for  the  corresponding  objects.  If  the  subject’s  trajectory  has 
been  previously  '  processed  by  SWP,  then  the  previous  FPCP 
encounters  for  the  subject  are  removed  from  the  IAW  Table  and 
are  identified  in  the  ESC_DECREMENT  Table  for  further  proces¬ 
sing.  Finally,  the  counts  on  the  various,  planned  actions  are 
added  to  the  RSW  Table  for  the  relevant  sector-time-intervals. 

Create  Subject  Sector  Time  Intervals 

In  example  of  how  the  sector-time-intervals  are  determined  is 
illustrated  in  Figure  4-4.  Hie  aircraft  begins  in  Sector  9  and 
travels  through  Sector  3  and  Sector  17.  A  new  sector-tirae- 
interval  corresponds  to  another  record- in  the  RSW  Table,  Table 
4-1  represents  a  RSW  Table  for  the  aircraft  depicted  in  Figure 
4-4.  In  this  example,  fifteen  minutes  is  used  for  the  value  of 
the  time-interval  duration  and  the  time-interval  id  is  set  to 
the  number  of  time-intervals  elapsed  since  noon. 

In  the  Create  Subject  Sector  Time  Interval  element,  information 
on  each  cell  in  the  subject's  grid  chain  is  used  to  identify 
the  sector-time-intervals  and  to  determine  the  subject's  con¬ 
tribution  to  the  sector  density.  Each  sector-time-interval  is 
identified  by  unique  beginning  and  ending  times.  The  Create 
Subject  Sector  Time  Interval  element,  illustrated  in  Figure 
4-5,  first  calculates  the  impact  of  the  subject  on  sector 
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ROUTINE  Indivldual_Aircraf t_Workload_Update ; 

REFER  TO  SHARED  LOCAL  Sflid  IN,  TrajectoryJJpdateJStatus  IN, 

SUBJECT  CELL  INOUT,  SUBJECT  BLOCK  INOUT,  CELL  DENSITY  INOUT, 

BLOCK  DENSITY  l^Ol^T;  ~~~  “ 

IF  Trajectory_Update_Status  E£  'REVISED' 

THEN  #remove  former  density  data  for  subject# 

REPEAT  FOR  EACH  SUBJECTjCELL  RECORD 

WHERE  SUBJECT_CELL . f l_id  E£  Sflid  AND  SU3JECT_CELL. 
aircraft_count  GT  0; 

UPDATE, IN  CELL_DENSITY  (aircraft_count  *  aircraft  count  -  1) 
WHERE  CELL_DENSITY. celljLd  SUBJECTJCELL. cell_id  AND 
CELL_DENSITY.beg_time  E£  SUBJECTJCELL. beg_time; 

UPDATE  IN  SUBJECTJCELL  (aircraft  jiount  *  0); 

REPEAT  FOR  EACH  SUBJECT  BLOCK  RECORD 

WHERE  SUBJECT_BLOCK.fl_id  E£  Sflid  AND  SUBJECT_BLOCK. 
aircraf  t_count  GT  0; 

UPDATE  IN  BLOCK_DENSITY  (aircraft_count  "  alrcraft_count-l) 
WHERE  BLOCKJDEN SITY . bio ck_id  E£  SUBJECT_BLOCK.blockJLd 
AND  BLOCK_DENSITY.beg_time  E£  SUBJECT  BLOCK, beg_time; 

UPDATE  IN  SUBJECT_BLOCK  (aircraf t_count  -  07; 

ELSE  Unitialize  density  data  for  subject# 

REPEAT  FOR  EACH  CELL_DENSITY  RECORD; 

INSERT  INTO  SUBJECTjCELL  (flJLd  -  Sflid,  cell_id  -  CELL 
DENSITY. cell_id,  beg  time  -  CELL_DENSITY .begjtime , 
aircraft  count  -  0,  ¥lock_id  »  CELL_DENSITY.block_id); 
REPEAT  FOR  EACH  BLOCK  DENSITY  RECORD; 

INSERT  INTO  SUBJECT_BLOCK  (flJLd  -  Sflid,  block_id  -  BLOCK_ 
DENSITY. blockjld,  beg_time  -  BLOCK_DEN SITY . be g_time , 
aircraf tjcount  *  0); 

CALL  Create_Subject_Sector_Time__Interval; 

CALL  Include_Subject_Encounters; 

CALL  Include_Object_Encounters ; 

CALL  Include__Subject_Planned_Actions; 

END  Individual_Aircraf t_Workload_Update ; 


FIGURE  4-3 

INDIVIDUAL  AIRCRAFT  WORKLOAD  UPDATE 


ROUTINE  Create_Subject_SectorJTime_Ii?.terval; 

REFER  TO  GLOBAL  SPARSEjCELLS  IN,  Time_Interval_Duration  IN 
REFER  TO  SHARED  LOCAL  Sflid  IN,  Delta  T  IN,  REVISED  SUBJECT  WORKLOAD 


ATFP* 

VVA  J 

#RSW  is  not  saved  after  the  logic  is  completed  for  the  subfunction# 
#Subject  Aircraft  Workload  Update  which  uses  this  element#' 

DEFINE  VARIABLES 

NoJEnd_Time  Number  records  in  End_Time  Array 

Time_Interval_Id  Time  interval  being  processed 

Ba'sic_Sector_Nun:ber  Basic  sector  being  processed 
Start_Cell_lIme  Beginning  time  for  x,y,t  cell 

End_Cell_Time  Ending  time  for  x,y,t  cell 

No_Sec  Number  of  unique  sectors  in  RSW  with  the  same 

ending  time 

No__SameJTime  Number  of  records  in  RSW  with  same  ending  time 

End_Time  (*)  Array  of  unique  ending  times  in  RSW 

I  Index; 


FIGURE  4-5 

CREATE  SUBJECT  SECTOR  TIME  INTERVAL 
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.  CALL  Calculate  Subject  Density; 

REPEAT  FOR  EACH  SPARSE_CELLS  RECORD 
WHERE  SPARSE_CELLS.fl_id  E£  Sflid; 

CALL  Calculate_Sector  (SPARSEJCELLS  IN,  Basic_Sector_Number  OUT); 
Tone  record  in  SPARSEjCELLS# 

Calculate  Start_Cell_Time  and  EndjCellJIime  from  time  part  of 
SPARSEjCELLS. tree_node_id  and  Time_Interval_Duration; 
Time_Interval_Id  *  time  interval  with  Start_Cell_Time  and  End_ 
CellJTime; 

INSERT  INTO  REVISED_SUBJECT_WORKLOAD 

#  1  record  in  RSW  corresponds  to  1  in  SPARSEjCELLS# 
(sector_number  “  Basic_Sector_Number,  time_interval_id  *  Time_ 
Interval_Id,  beginning_time  *  Start__CellJTime,  ending_time  ” 
End_Cell_Time,  total_fl_time  *  0,pa_counts  "  0); 

SELECT  FIELDS  UNIQUE  ending_time  ■ 

FROM  REVI  SEDJSUB JECTJWORKLOAD 
RETURN  COUNT  (No  EndJTime) 

INTO  EndJTime  IFarray# 

ORDER  BY  ending_time; 

FOR  I  *  1  TO  No_End_Time;  #loop  on  number  of  unique  ending  times# 
SELECT  FIELDS  ending_time 

FROM  REV ISED_SUBJECTJWORKLOAD  (RSW) 

RETURN  COUNT  (No  Same  Time) 

WHERfe  RSW. ending  time  E£  EndJTime(I ) ; 

IF  No  Same_Time  GT1 

THEN  7decide  if  aircraft  in  more  than  1  sector  with  this  cell's# 
#ending  time# 

SELECT  FIELDS  UNIQUE  sectorjnumber 
FROM  REVISED_SUB JECTJWORKLOAD  (RSW) 

WHERE  RS W . ending_t ime  E£  End_Time(I) 

RETURN  COUNT  (No_Sec); 

#No_Same_Time  is  still  more  than  1# 

IF  No  Sec  GT  1 

THEN  Jdecide  which  sector  to  use  for  this  end  time# 

SELECT  FIELDS  sector_uumber 

FROM  REV ISEDJSUBJECT_W0RKL0AD  (RSW) 

INTO  Basic_Sector_Number 

WHERE  RSW . ending_t ime  E^  End_Time(I)  -  Delta_T; 

DELETE  FROM.  REVI SED_SUB JECTJWORKLOAD  (RSW) 

WHERE  RSW.ending_time  EQ  EndJTime(I) 

AND  RSW. sector  jaumber  NE  Basic_Sector_Number; 

CALL  Detennine_Unique_SectorJTime_Intervals ; 

#to  make  in  RSW  one  record  per  sector  time  interval# 

END  Create_Subject_Sector_Time_Interval; 


FIGURE  4-5 

CREATE_SUBJECT_SECTORJTIME_INTERVAL  (Concluded) 
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density  on  both  the  cell  and  block  level  as  discussed  in  Figure 
4-6.  The  sector  and  some  time  information  are  computed  for 
each  cell.  The  REVISED_SUBJECT_WORKLOAD  Table  undergoes 
several  stages  from  the  case  where  each  record  contains  infor¬ 
mation  on  each  cell  in  the  subject’s  grid  chain  to  the  case 
where  each  record  represents  a  unique  sector-timeinterval.  In 
the  first  stage  of  the  RSW  Table,  each  cell  in  the  subject’s 
grid  chain  (SPARSEjCELLS)  is  examined.  The  sector  which  con¬ 
tains  the  cell  is  determined  by  the  Calculate  Sector  element 
shown  in  Figure  4-7.  The  StartjCellJTime ,  End_Cell_Time ,  and 
Time_Interval__Id  are  computed  and  these  are  included  in  a 
record  for  the  cell  in  the  RSW  Table.  The  Start_Cell_Time  is 
the  earliest  time  associated  with  the  specific  cell  in  the  grid 
chain,  while  the  EndjCellJEime  is  the  latest  time  associated 
with  this  cell.  The  Time_Interval_Id  designates  the  time  in¬ 
terval  which  encompasses  the  time  range  of  this  cell.  In  the 
second  stage  of  the  RSW  Table,  the  unique  ending  times  in  RSW 
are  stored  and  processed  individually.  The  REVISED_SUBJECT_ 
WORKLOAD  Table  may  contain  multiple  records  with  the  same 
ending  time  (i.e.,  the  x  and  y  values  changed  with  the  t  values 
remaining  the  same)-.  If  such  multiple  records  exist  for  the 
same  ending  time,  then  tests  are  performed  to  determine  which 
sector  to  associate  with  these  RSW  records.  If  the  RSW  Table 
contains  more  than  one  record  with  the  specific  cell  ending 
time,  then  the  routine  determines  if  the  aircraft  is  in  more 
than  one  sector  among  these  records.  When  these  records  have 
more  than  one  sector  with  the  same  cell  ending  time,  the  sector 
with  the  last  processed  cell  ending  time  is  chosen  as  the  sec¬ 
tor  with  the  current  cell  ending  time  and  the  records  with 
other  sectors  for  the  current  cell  ending  time  are  deleted. 
After  all  unique  ending  times  have  been  processed,  the  Deter¬ 
mine  Unique  Sector-Time-Intervals  element  produces  the  stage  of 
the  RSW  Table  where  each  record  represents  a  sector-time- 
interval.  In  this  element,  depicted  in  Figure  4-8,  the  unique 
sector  and  time-interval  pairs  are  selected  and  their  beginning 
and  ending  times  are  computed  to  produce,  the  RSW  Table  before 
the  data  are  included  on  the  workload  measures. 

Calculate  Subject  Density 

The  Calculate  Subject  Density  element,  shown  in  Figure  4-6, 
first  processes  density  at  the  cell  level  and  then  at  the  block 
level.  A  local  table,  SUBJECT_DENSITY,  is  used  to  store  the 
cell  occupancy  of  the  subject  aircraft.  The  aircraft  count 
field  of  this  table  is  initialized  to  zero.  For  each  cell  (in 
x,  y,  t)  in  the  grid  chain  (SPARSEjCELLS),  the  corresponding 
records  in  the  sector  airspace  grid  (SWPjCELL)  are  examined 
where  the  x  and  y  dimensions  have  the  same  values.  Providing 
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ROUTINE  Calculate_Subject_Densityj 

REFER  TO  GLOBAL  SWP  CELL  IN,  SPARSE  CELLS  IN; 

REFER  TO  SHARED  LOCAL  Sflid  IN,  SUBJECTJJELL  INPUT,  SUBJECTJBLOCK 
INPUT,  CELLJDENSITY  INPUT,  BLOCK_DENSITY  INPUT; 

DEFINE  VARIABLES 

StartjCellJTime  Beginning  time  for  x,y,t  cell 
Cell_Count  Number  of  cells  occupied  by  the  subject 

aircraft  in  one  block; 


FIGURE  4-6 

CALCULATE  SUBJECT  DENSITY 
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Iprocessing  at  the  cell  level# 

#8 tore  cell  occupancy  of  subject  aircraft  in  SUBJECTJCELL# 

REPEAT  FOR  EACH  SPARSE_CELLS  RECORD  #in  x,y,t# 

#For  given  values  of  x,y  in  SPARSE_CELLS  repeat  for  z  in  SWPjCELL# 
WHERE  SPARSE_CELLS.fl  id  Eg  Sflid; 

REPEAT  FOR  EACH  SWPjCELL  RECORD  #in  x,y,z# 

WHERE  x,y  dimensions  of  SWPJCELL  correspond  to  x,y  dimensions 
of  SPARSE  CELLS;  #range  of  z  in  center  is  covered  # 

IF  interval  TSPARSEJCELLS  .min_z ,  SPARSE JCELLS  .max_z)  and 
interval  ( SWPjCELL . min_altitude ,  SWPJCELL . max_altitude ) 
overlap 

THEN  #aircraft  occupies  this  x,y,z  cell# 

Calculate  Start_Cell_Time  from  time  part  of  SPARSEjCELLS . 
tree_node_id; 

#add  cell  occupancy  of  subject  aircraft  (to  SUBJECTJ# 

#CELL  and  to  CELL_DENSITY )# 

UPDATE  IN  CRLL_DENSITY  (aircraft_count  “aircraf  t_count  +  1) 
WHERE  CELL_DENSITY. celljLd  Eg  SWPJCELL. cell_id  AND 
CELL_DENSI TY . beg_t ime  Eg  Start_Cell_Time; ' 

UPDATE  IN  SUBJECT  CELL  (aircraft  count  ■  aircraft  count 

+  1) 

WHERE  SUBJECTJCELL.  celljLd  Eg  SWPjCELL.  celljLd  AND 
SUBJECTJCELL. begjtime  Eg  StartjCellJTime  AND 
SUBJECT_DENSITY.fl_id  Eg  Sflid; 

#Processing  at  the  block  level# 

#Use  cell  occupancy  of  subject  to  get  block  occupancy# 

REPEAT  FOR  EACH  BLOCK  DENSITY  RECORD; 

SELECT  FIELDS  ALL 

RETURN  COUNT  (Cell_Count) 

FROM  SUBJECTJCELL 

WHERE  SUBJECTJCELL. aircraft_count  GT  0  AND  SUBJECTJCELL. 
blockjtd  Eg  BLOCK_DENSITY .blockjld  AND  SUBJECT_  CELL.beg_ 
time  is  within  the  time  interval  defined  by  BLOCK 
DENSITY. beg_time  AND  SUBJECT_DENSITY.fl_id  Eg  Sflid; 

IF  CelljCount  GT  0 
THEN 

UPDATE  IN  BLOCK_DENSITY  (aircraft_count  -  aircraft_count  +  1); 
UPDATE  IN  SUBJECT_BLOCK  (aircraf tjcount  *  aircraf  t_count  +  1) 
WHERE  SUBJECT_BLOCK.fl_id  Eg  Sflid  AND  SUBJECT_BLOCK. 
blockjtd  Eg.  BLOCK_DENSITY. block  JLd  AND  SUBJECT_ 

BLOCK. beg_time  Eg  BLOCK_DENSITY.beg_time; 

END  Calculate_Subject_Density; 


FIGURE  4-6 

CALCULATE_SUBJECT_DENSITY  (Concluded) 
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ROUTINE  Calculate_Sector; 

# routine  called  during  processing  of  one  SPARSEjCELLS  record# 

#this  routine  determines  the  basic  sector  which  is  associated  with# 
#one  cell  of  SPARSEJCELLS  (in  x,y,t)  based  on  the  sector  with  the# 
#greatest  change  in  altitude  over  the  x,y,t  cell# 

PARAMETERS  CELL  IN,  Basic_Sector_Number  OUT; 

REFER  TO  GLOBAL  SWP  CELL  IN,  SPARSE  CELLS  IN; 

DEFINE  VARIABLES 

BasicJSector  Number  Basic  sector  for  x,y  cell 
Alt_Overlap 
No_Sectors 
DEFINE  TABLES 
CELL 


P0SS_SECT0RS 
celljtd 
diffjalt 
sector_number 
REPEAT  FOR  EACH  SWPJCELL  RECORD  #in  x,y,z# 

WHERE  x,y  dimensions  of  SWPJCELL  correspond  to  x  ,y  dimensions  of 
CELL;  #repeat  for  z  divisions  in  SWPJCELL  for  x,y  # 

IF  interval  (CELL.min_z,  CELL.max_z)  and  interval  (SWPJCELL. 

min_altitude,  SWPjCELL. max_altitude)  overlap 
THEN 

^intersection  of  altitude  ranges# 

Alt_Overlap  *  amount  of  overlap; 

INSERT  INTO  P0SSJ3ECT0RS  (celljld  «  SWP_CELL.cell_id,  diff_ 
alt  "  Alt_Overlap,  sector_number  *  SWPjCELL. sector_ 
number); 

No_Sectors  ■  COUNT  (unique  values  of  POSS_SECTORS.sector_number) ; 

IF  No_Sectors  E^  1 
THEN 

Basic_Sector_Number  ■  unique  POSSJSECTORS.sectorjnumber; 

ELSE 

Basic_Sector_Number  *  sector  with  the  maximum  sum  of  P0SS_ 
SECTORS. diff_alt; 

END  Calculate  Sector; 


Overlap  of  altitude  for  subject  with  x,y,z 

Number  of  sectors  associated  with  CELL; 

Contains  Information  on  one  cell  in  the  grid 
chain  (SPARSE_CELLS);  fields  defined  like 
SPARSEJCELLS 

Possible  sectors  associated  with  CELL.cell__id 
Cell  in  x,y,z 
Altitude  overlap 
Basic  sector; 


FIGURE  4-7  • 

CALCULATE  SECTOR 
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ROUTINE  Determine  Unique  Sector  Time  Intervals ; 

REFER  TO  SHARED  LOCAL  REVISED  SUBJECT  WORKLOAD  INOUT; 
DEFINE  VARIABLES 


Min_Time 
Max_Time 
End_Time  (*) 
Beg_Time  (*) 


Minimum  of  beginning  times  examined 
Maximum  of  ending  times  examined 
Array  of  unique  ending  times  in  RSW 
Array  of  unique  beginning  times  in 
RSW; 


DEFINE  TABLES 

SEC_TI  Sector  time  interval  table 

sector_number  Basic  sector 

time_interval_id  Corresponding  time  interval; 

SEC_TI  *  SELECT  FIELDS  UNIQUE  sector_number,  time_interval_id 

FROM  REVISED  SUBJECT  WORKLOAD;  #unique . field  pairs# 
REPEAT  FOR  EACH  SEC_TI  RECORD;  #determine  beginning  time  and# 
#ending  time  for  each  sector  time  interval# 

#determine  beginning  time  of  sector  time  interval# 

SELECT  FIELDS  UNIQUE  beginning_time 
FROM  REVISED  SUBJECT  WORKLOAD  (RSW) 

INTO  Beg_Time  #array # 

WHERE  RSW. sectorjiumber  EQ  SEC_TI.  sectorjiumber  AND 
RSW. time  interval  id  EQ  SEC_TI.time_interval_id; 

MinJTime  ”  MINTBeg  TimeT ;  #MIN  is  a  builtin  function# 
#determine  ending  time  of  sector  time  interval# 

SELECT  FIELDS  UNIQUE  ending_time 

FROM  REVISED_SUBJECT  WORKLOAD  (RSW) 

INTO  End_Time  #array? 

WHERE  RSW.sector_number  EQ,  SEC_TI.sector_number  AND  RSW. 
timejLntervaljld  EQ  SECJTI.timejLntervaljLd; 

MaxJIime  ■  MAX  (EndJTime);  #MAX  is  a  builtin  function# 

DELETE  FROM  REVISED_SUBJECT_WORKLQAD  (RSW)  #delete  records  in# 
#RSW  for  x,  y,  z,  t  cells  related  to  sector  time  interval# 
WHERE  RSW.sectorjaumber  SEC_TI . sectorjiumber  AND  RSW. 

.  timejinterval_id  E^  SEC_TI.time_interval_id; 

INSERT  INTO  REVISED_SUBJECT_WORKLOAD 

#add  1  record  In  RSW  for  sector  time  interval# 
(sectorjaumber  M  SEC_TI. sectorjiumber,  timejLntervaljLd  ** 
SEC_TI.  timejLntervaljld,  beginning_time  *  Min_Time,  ending_ 
time  ■  Max_Time,  total_fl_time  “0,  FPCP_encounter_count  ■ 
0,  AP_encounter_count  “  0,  pa_counts  “  0); 

#end  of  sector  time  interval  logic# 

END  Determine_Unique_Sector_Time_Intervals; 


FIGURE  4-8 

DETERMINE jmQUE_SECTORJDIME_INTERVALS 
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the  altitude  for  the  grid  chain  cell  overlaps  that  for  the  sec¬ 
tor  airspace  grid  cell,  the  aircraft’s  occupancy  is  included  in 
the  cell  density  airspace  grid  (CELL_DENSITY)  and  in  SUBJECT_ 
DENSITY.  Next,  processing  of  density  at  the  block  level  uses 
the  cell  occupancy  of  the  subject  to  add  to  the  block  occupancy 
of  all  aircraft.  For  each  block  density  airspace  grid  (BL0CK_ 
DENSITY)  block,  a  count  (CelljCount)  is  made  for  the  number  of 
occupied  cells  in  the  cell  density  airspace  grid  corresponding 
to  this  block.  If  CelljCount  is  greater  than  zero,  then  the 
aircraft  count  field  In  BLOCK_DENSITY  is  incremented. 

Calculate  Sector 


The  sector  associated  with  a  cell  in  the  subject's  grid  chain 
is  determined  by  the  Calculate  Sector  element  displayed  in 
Figure  4-7.  The  cells  in  the  sector  airspace  grid  (SWPjCELL) 
which  have  values  in  the  x  and  y  dimensions  equal  to  those  in 
the  subject's  grid  chain  cell  are  examined  to  see  if  the  alti¬ 
tude  intervals  of  these  cells  overlap.  If  the  altitude 
intervals  overlap,  the  cell  id,  sector  number  and  amount  of 
overlap  are  stored  in  POSSJSECTORS .  For  one  cell  in  the  grid 
chain,  the  aircraft  may  be  in  more  than  one  cell  in  the  sector 
airspace  grid;  therefore,  the  number  of  unique  sectors  in 
P0SS_SECT0RS  is  counted.  If  the  number  of  unique  sectors  is 
not  equal  to  one,  the  sector  corresponding  to  the  grid  chain 
cell  is  determined  to  be  the  sector  with  the  maximum  sum  of 
altitude  overlap  in  P0SS_SECT0RS. 

Determine  Unique  Sector  Time  Intervals 

The  Determine  Unique  Sector  Time  Intervals  element,  described 
in  Figure  4-8,  processes  and  consolidates  information  in  the 
RSW  Table  such  that  this  table  is  output  containing  only  one 
record  for  each  sector-time-interval.  First  the  unique  pairs 
of  sector  number  and  time-interval  id  are  selected  into  a  local 
table  (SECJTI).  For  each  record  in  SJ5CJTI,  the  beginning  time 
and  ending  time  are  computed  from  records  in  RSW  with  the  same 
sector  and  time-interval.  The  beginning  time  is  calculated  as 
the  minimum  of  the  BegJTime  in  these  RSW  records;  the  ending 
time  is  computed  to  be  the  maximum  of  the  EndJTlme  in  these 
records.  Next,  the  records  in  the  RSW  Table  with  the  same  sec¬ 
tor  number  and  time-interval  are  deleted  and  one  new  record  is 
added  with  the  beginning  time  and  ending  time  for  the  entire 
time-interval. 


Include  Subject  Encounters 


After  the  Create  Subject  Sector  Time  Interval  element  is  com¬ 
pleted,  the  Include  Subject  Encounters  element  described  in 
Figure  4-9  is  processed.  The  Include  Subject  Encounters  ele¬ 
ment  processes  separately  the  FPCP  encounters  and  AP  encounters 
for  the  subject  and  updates  the  encounter  counts  in  the  appro¬ 
priate  sector-time-interval  in  the  RSW  Table.  For  the  FPCP 
encounters,  the  display-as-advisory  time  in  ENCOUNTERS  is  com¬ 
pared  to  the  sector-time-interval  beginning  time  and  ending 
time.  For  the  AP  encounters,  the  display-as-advisory  time  is 
computed  as  the  current  time  or  the  time  of  penetration  of  the 
static  airspace  subtract  the  AP_Not_Dur.  Similarly,  the 
display-as-advisory  time  for  the  AP  encounters  is  compared  to 
the  sector-time-interval  beginning  time  and  ending  time. 

Include  Object  Encounters 

The  FPCP  encounters  for  the  subject  affect  gome  object 
aircraft — specifically  the  ESC  aircraft.  The  purpose  of  the 
Include  Object  Encounters  element,  displayed  in  Figure  4-10,  is 
to  designate  the  ESC  aircraft  and  to  update  the  FPCP  encounter 
count  for  their  records  in  the  IAW  Table.  First  the  records  in 
ENCOUNTERS  for  the  current  encounters  are  processed.  The  FPCP 
encounter  count  in  the  new  sector-time-interval  is  incremented 
by  one.  Information  on  this  ESC  aircraft  is  inserted  in  the 
ESC_INCREMENT  Table.  Secondly,  the  records  in  PRIOR_ENCOUNTERS 
for  the  .previous  encounters  are  processed.  The  FPCP  encounter 
count  in  the  former  sector-time-interval  is  decremented  by  one 
and  data  on  this  object  are  inserted  in  the  ESC_DECREMENT 
Table.  Two  ESC  Tables  have  been  created  which  will  be  used  by 
the  Basic  Sector  Workload  Update  component  to  update  the  BASIC_ 
SECTOR_WORKLOAD_MEASURES  Table. 

Include  Subject  Planned  Actions 

Data  on  another  workload  measure — the  planned  actions — are 
incorporated  in  the  RSW  Table  by  Include  Subject  Planned 
Actions  element  depicted  in  Figure  4-11.  Each  planned  action 
in  PLANNED_ACTIONS  for  the  subject  is  processed.  The  start 
time  of  the  planned  action  is  obtained  from  PLANNED_ACTION_ 
DURATION  for  the  corresponding  planned  .  action.  Next  the 
sector-time-interval  in  RSW  which  contains  the  planned  action 
start  time  is  located  and  the  count  for  this  planned  action 
type  is  Incremented  by  one*. 
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ROUTINE  Include_Subject_Encounters; 

REFER  TO  GLOBAL  ENCOUNTERS  IN,  ENVIRONMENTALjCONFLICT  IN; 

REFER  TO  SHARED  LOCAL  REVISED  SUBJECT  WORKLOAD  INOUT,  AP  Not  Dur  IN, 

- gma_ - - -  -  _  _  _ 

#Frocess  FPCP  Encounters# 

REPEAT  FOR  EACH  ENCOUNTERS  RECORD 

WHERE  ENCOUNTERS.  firstjElj'.d  E£  Sflid  OR  ENCOUNTERS. second_fl_ 
id  E£  Sflid; 

REPEAT  FOR  EACH  REVISEDJSUBJECTJWORKLOAD  (RSW)  RECORD 

WHERE  RSW.beginning_time  LE  ENCOUNTERS. display_as_advi8ory_ 
time  AND  RSW.ending_time  GT  ENCOUNTERS. display_as_ 
advi8ory_time; 

UPDATE  IN  REVISEDJSUBJECTJWORKLOAD  (FPCP_encounter_count  - 
FPCP_encounter_count  +1); 

#Proces8  AP  Encounters# 

REPEAT  FOR  EACH  ENVIRONMENTAL_CONFLICT  RECORD 
WHERE  ENVIRONMENTAL_CONFLICT. f l_id  E£  Sflid; 

REPEAT  FOR  EACH  REVISED  SUBJECT  WORKLOAD  (RSW)  RECORD 

WHERE  RSW . beginning__t ime  LE  (ENVIRONMENTALJCONFLICT.  time  - 
AP_Not_Dur)  AND  RSW. ending  time  GT  ( ENV IRONMENTAL_ 
CONFLICT. time  -  AP_Not_DurT; 

UPDATE  IN  REVISED_SUBJECT_WORKLOAD  (AP_encount3r_count  - 
AP_encounter_count  +  1); 

END  Include_Subject_Encounters; 


FIGURE  4-9 

INCLUDE  SUBJECT  ENCOUNTERS 
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ROUTINE  Include  Object  Encounters; 

REFER  TO  GLOBAL  ENCOUNTERS  IN,  PRIOR  ENCOUNTERS  IN; 

REFER  TO  SHARED  LOCAL  ESC  INCREMENT  OUT,  ESC  DECREMENT  OUT, 

INDIVIDUAL_AIRCRAFT_WORKLOAD  INPUT,  Sflid  IN,  Trajectory_Update_ 
Status  IN; 

REPEAT  FOR  EACH  ENCOUNTERS  RECORD 

#add  FPCP  encounters  for  object  to  ESC_INCREMENT  table# 

WHERE  ENCOUNTERS. first  fl  id  EQ  Sflid  OR  ENCOUNTERS. second  fl  id 
E£  Sflid; 

#Note  hereafter  first_fl_id  represents  the  subject’s  flid,  # 
#second_fl_id  represents  object’s  flid# 

REPEAT  FOR  EACH  INDIVIDUAL  AIRCRAFT  WORKLOAD  (LAW)  RECORD 

WHERE  IAW.fl_id  E£  ENCOUNTERS. second_flJLd  AND  IAW. beginning 
time  LE  ENCOUNTERS . display_as_advisory_time  AND  LAW. 
endingjtime  GT  ENCOUNTERS. display_a8_advisory_time; 

UPDATE  IN  INDIVIDUAL_AIRCRAFT_WORKLOAD  (FPCP_encounter_count 
“  FPCP_encounter_count  +  1); 

INSERT  INTO  ESC_INCREMENT  (fl_id  -  INDIVIDUAL_AIRCRAFT_ 
WORKLOAD.  fl_id,  sectornumber  -  INDIVIDUAL_AIRCRAFT_ 
WORKLOAD. sector_number,  time_interval_id  *  INDIVIDUAL_ 
AIRCRAFT_WORKLOAD. timeJLntervalJLd) ; 

IF  Trajectory_Update_Status  EQ  ' REVISED ’#not  a  new  trajectory# 

THEN  #remove  previous  FPCP  encounters  for  subject  from  IAW  table# 
#and  add  previous  FPCP  encounters  for  objects  to  ESC_DECREMENT# 
#table# 

REPEAT  FOR  EACH  PRIOR__ENCOUNTERS  RECORD 

WHERE  PRIOR  ENCOUNTERS. first  fl  id  EQ  Sflid  OR  PRIOR 
ENCOUNTERS . s econd_f  lJLd  EQ  Sflid ; 

REPEAT  FOR  EACH  INDIVIDUAL  AIRCRAFT  WORKLOAD  (IAW)  RECORD 
WHERE  IAW.flid  EQ  PRIOR_ENCOUNTERS . second_f lid  AND  IAW. 
beginningjtime  LE  PRIOR_ENCOUNTERS.display_as_advisory_ 
time  AND  IAW.ending_time  GT  PRI0R_  ENCOUNTERS. display_ 
a  8_advis  ory_time ; 

UPDATE  IN  INDIVIDUAL_AIRCRAFT_WORKLOAD  (FPCP_encounter_ 
count  “  FPCP_encounter_count  -  1); 

INSERT  INTO  ESC_DECREMENT“ (fl_id  -  INDIVIDUAL_AIRCRAFT_ 
WORKLOAD. fl_id,  sector_number  «  INDIV IDUAL_AIRCRAFT_ 
WORKLOAD. 8ector_number,  timc_interval_id  “  INDIVIDUAL_ 
AIRCRAFT_WORKLOAD.time  intervalJLd); 

DELETE  FROM  PRIOR_ENCOUNTERS;  Tentire  table# 

END  Include_Object's_Encounters; 


FIGURE  4-10 

INCLUDE  OBJECT  ENCOUNTERS 
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ROUTINE  Include_Sub ject_Planned_Actions : 

REFIR  TO  GLOBAL  PLANNED_ACTIONS  IN,  PLANNED_ACTION_DURATION  IN; 

REFER  TO  SHARED  LOCAL  REVISED  SUBJECT  WORKLOAD  INOUT;  Sflid  IN; 

DEFINE  VARIABLES 

Pa_Start :JTime  Time  planned  action  being  processed  begins; 

#type  of  pa  count  refers  to  the  count  on  one  of  the  pa  types  in# 
#RSW,  i.e.,  whichever  one  is  appropriate# 

REPEAT  FOR  EACH  PLANNED  ACTIONS  RECORD 
WHERE  PLANNED_ACTIONS.fl_id  E£>  Sflid; 

SELECT  FIELDS  pa  start  time 
FROM  PLANNED_ACTION_DURATION 
INTO  Pa  Start  Time 

WHERE  PLANNED”ACTION_DURATION . pa_id  E£  PLANNED_ACTIONS.pa_id; 
REPEAT  FOR  EACH  REVI SED_SUB JECT_W0RKL0AD  (RSW)  RECORD 

WHERE  RSW.beginning_time  LE  Pa_Start_Time  AND  RSW.ending_time 
GT  Pa_S  tart_Time ; 

UPDATE  IN  REVISED__SUBJECT_WORKLOAD  (increment  type  of  pa 
count  by  1  for  which  the  type  of  pa  count  is  the  PLANNED_ 
ACTIONS . pa_type) ; 

END  Include_Sub ject_Planned_Actions ; 


FIGURE  4-11 

INCLUDE_SUBJECT_PLANNED_ACTIONS 
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4.1.2  Basic  Sector  Workload  Update  Component 
4. 1.2.1  Mission 


The  purpose  of  the  Basic  Sector  Workload  Update  component  is  to 
update  the  workload  measures  in  the  BASIC_SECTOR_WORKLOAD_ 
MEASURES  Table,  to  reflect  the  changes  due  to  a  trajectory 
update.  The  IAW  Table  records  for  the  subject  aircraft  are 
also  updated  or  created. 

4. 1.2. 2  Design  Considerations  and  Component  Environment 


Input 

The  input  data  contain  the  IAW  Table,  the  '  RSW  Table,  ESC 
Tables,  BASIC_SECTOR__WORKLOAD_MEASURES  Table,  the  subject 
flight  identifier,  and  the  status  of  the  trajectory  update  (new 
or  revised).  The  BASIC_SECTOR_WORKLQAD_MEASURES  Table  has  the 
data  on  the  aggregate  aircraft  according  to  sectors  and  time- 
intervals,  for. all  basic  sectors  in  the  center  and  for  all 
time-intervals  within  the  time  horizon. 

Output 

The  primary  output  is  the  BASIC_SECTOR_WORKLOAD_MEASURES  Table 
updated  to  reflect  the  trajectory  update,  including,  for  each 
time-interval  and  sector  pair: 

•  Total  flight  time 

•  Number  of  planned  actions  according  to  type 

•  Number  of  encounters  from  AP  and  FPCP 

The  subject’s  records  in  the  IAW  Table  are  also  updated. 

4. 1.2, 3  Component  Design  Logic 

The  Basic  Sector  Workload  Update  logic,  shown  in  Figure  4-12, 
begins  with  the  addition  of  the  data  from  the  RSW  Table  to  the 
BASIC_SECTORJWORKLQAD_MEASURES  (BSWM)  Table.  For  each 
sector-time-interval  in  the  RSW  Table,  the  corresponding 
sector-time-intervals  in  the  BSWM  Table  are  examined  to  deter¬ 
mine  which  sector  and  time-interval  are  affected.  For  each  such 
pair,  the  following  RSW  Table  values  are  added  to  the  corres¬ 
ponding  BSWM  Table  values:  aircraft  minutes,  counts  on  planned 
actions,  and  count  on  Airspace  Probe  and  Flight  Plan  Conflict 
Probe  encounters. 
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v  V  , 


ROUTINE  Allobject_Workload_Update; 

REFER  TO  GLOBAL  BASIC_SECTOR_WORKLQAD_MEASURES  INPUT; 

REFER  TO  SHARED  LOCAL  REVISEDJ3UBJECT_WORKLOAD  IN,  INDIVIDUAL_ 
AIRCRAFT_WORKLQAD  INPUT,  Sflid  IN,  Trajectory_Update_Status  IN, 
ESC_INCREMENT  IN,  ESC_DECREMENT  IN; 

#  In  this  routine,  for  purposes  of  clarity  and  simplicity,  the  # 

#  following  abbreviations  are  used:  # 

#  RSW  for  REVISED_SUBJECT_WORKLOAD  # 

#  IAW  for  INDIVIDUAL  AIRCRAFT  WORKLOAD  # 


FIGURE  4-12 

BASIC  SECTOR  WORKLOAD  UPDATE 


REPEAT  FOR  EACH  REVISED_SUBJECT_WCRKLOAD  (RSW)  RECORD; 

#add  workload  for  subject  to  that  for  all  aircraft# 

UPDATE  IN  BASI C_SECTOR_WORKLOAD_MEASURES  (BSWM)(total_fl_time  - 
total_fl_time  +  RSW.total_fl_time,  fpjconflictjcount  *  fp_ 
conflict_count  +  RSW.FPCP_encounter__count,  airspace_conflict_ 
count  *  AP_conflict_count  +  RSW.AP_encounter_count,  pa_counts  ■ 
RSW. pa_counts ) ; 

WHERE  BSWM.time_interval_id  EQ  RSW.time_interval_id  AND 
BSWM.sector_number  E(£  RSW.sector_number; 

IF  Trajectory_Update_Status  E^  'REVISED’ . 

THEN 

REPEAT  FOR  EACH  INDIVIDUAL_AIRCRAFT_WORKLOAD  (IAW)  RECORD 
#subtract  previous  workload  for  subject  from  that  for  all  aircraft# 
WHERE  IAW.fljLd  E£  Sflid; 

UPDATE  IN  BASIC_SECTOR_WORKLOAD_MEASURES  (BSWM)(total_fl_time  - 
total_fl_time  -  IAW..  total_f l_time ,  fp_conflict_count  “  fp_ 
conflict_count  -  IAW,FPCP_enccunter_count,  airspace_ 
conflictjcount  *  airspacejconflictjcount  -  IAW.AP_encounter_ 
count,  pajcounts  =  pa_counts  -  IAW.pajcounts) 

WHERE  BSWM.sector_number  E^  IAW.sector_number  AND  BSWM.time_ 
intervai__Id  EC[  IAW. time  JLnterval_id; 

REPEAT  FOR  EACH  ESCJNCREMENT  RECORD  #add  to  FPCP  encounters  for# 
#objects# 

UPDATE  IN  BASIC_SECTOR_WORKLOAD_MEASURES  (BSWM)  (fp_conflict_ 
count  *  fpjconflictjcount  +  1) 

•  WHERE  BSWM.sector_number  E^  ESC_INCREMENT.sector_nuober  AND 

BSWM.tlme_interval_id  E^  ESC_INCREMENT.time_interval_idj 
REPEAT  FOR  EACH  ESC  DECREMENT  RECORD  #dacrease  number  of  FPCP  # 
#encounters  for  objects# 

UPDATE  IN  BASIC_SECTOR_WORKLOAD_MEASUR£S  (BSWM)  (fp_conflict_ 
count  ■  fp_conflict_count  -  1) 

WHERE  BSWM.sectorjnumber  E^  ESC_DECREMENT.sector_number  AND 
BSWM. timeJLntervaljLd  Ej£  ESC_DECREMENT.timejLnterval_idj 
DELETE  FROM  INDIVIDUAL_AIRCRAFT_WORKLOAD  (IAW) 

#remove  subject's  previous  workload# 

WHERE  IAW.fljLd  E^  Sflid; 

REPEAT  FOR  EACH  REVISED_SUBJECT  WORKLOAD  RECORD 
”  #save  subject's  new  workload? 

INSERT  INTO  INDIVIDUAL_AIRCRAFT_WORKLOAD  (IAW)  (fl_id  -  Sflid, 
sector_number  ■  RSW.sector_number,  timeJLnterval_id  *  RSW.time_ 
interval_id,  beginning_time  =  RSW.beginning_time,  ending_time  “ 
RSW.ending_time,  total_fl_time  “  RSW.total_fl_time,  FPCP_ 
encounter_count  ■  RSW.FPCP_encounter_count,  AP_encounter_count 

*  RSW.APjencounterjcount,  pajcounts  »  RSW.pa_counts); 

END  Allobject_Workload_Update; 

FIGURE  4-12 

BASIC  SECTOR  WORKLOAD  UPDATE  (Concluded) 
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If  the  status  of  the  trajectory  update  indicates  that  a  revision 
to  the  trajectory  has  occurred,  then  a  process  similar  to  that 
described  above  is  performed  with  the  subtraction  of  the  values 
in  the  subject's  records  of  the  IAW  Table  from  the  corresponding 
BASI C_SECTOR_WORKLOAD_MEASUHES  Table  values. 

The  updating  of  the  BASIC_SECTOR_WORKLOAD_MEASURES  Table  counts 
for  FPCP  encounters  is  not  yet  complete:  The  old  workload 

Information  has  been  deleted  and  the  new  workload  information 
added  for  the  subject  but  not  yet  for  the  ESC  objects.  To  do 
so,  the  algorithm  uses  the  ESC  Tables  to  subtract  the  old 

encounter  counts  and  add  the  new  ones  to  the  BASIC  SECTOR 
WORKLQAD_M£ASURES  Table. 

The  data  in  the  subject's  records  in  the  IAW  Table  (reflecting  a 
previous  trajectory  update)  are  no  longer  needed  and  are  there¬ 
fore  deleted.  The  RSW  Table  data  are  inserted  in  the  IAW  Table. 

4.2  Supervisor  Requests  Subfunction 

The  Supervisor  Requests  subfunction  is  invoked  by  the  supervisor 
for  one  of  the  following  reasons: 

•  To  display  the  outputs  for  the  sectors  in  this  super¬ 
visor's  area  or  any  set  of  sectors  in  the  planning 

region  (Immediate  Mode  Request  or  Conditional  Mode 
Request) 

•  To  set  a  threshold  on  a  sector  and  workload  measure 

(Conditional  Mode  Request) 

•  To  edit  the  display  features  of  the  outputs 

In  this  subfunction,  workload  is  handled  in  terms  of  aggregate 
aircraft  categorized  by  sectors  and  time-intervals,  using  the 
BASIC_SECTOR_WORKLOAD_MEASURES  Table,  but  not  the  INDIVIDUAL_ 
AIRCRAFTJWORKLOAD  Table. 

The  values  of  several  user-selected  variables  are  required  in 
order  that  the  Supervisor  Requests  subfunction  can  set  the 
values  of  the  corresponding  shared  local  parameters  described 
in  Appendix  A.  These  user-selected  variables  are  as  follows: 

•  Request_Type 

•  Organization  Type  (OrganJType) 

•  Periodic_Frequency 

•  Area_Name 

•  List  Of  Sectors 
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•  Ac_Count_Option 

•  Weight ed_Pa_Option 

•  DensityjOption 

•  0veralI_Workload_0ption 

Default  values  may  be  used  for  some  of  these  variables,  if  not 
input  by  the  supervisor. 

The  Supervisor  Requests  subfunction  also  requires  as  input  the 
sectorization  plan  (SECTORIZATION_PEAN)  and  the  sectorization 
schedule  (SECTORIZATION_SCHEDULE).  The  values  in  the 
SECTORIZATION_PLAN  Table  are  updated  infrequently,  but  the 
values  in  the  SECTORIZATION_SCHEDULE  Table  are  updated  by  the 
supervisor  as  the  schedule  changes. 

The  outputs  of  the  Supervisor  Requests  subfunction  include  the 
BASIC_SECT0R_V70RKL0AD_MEASURES  Table,  the  COMBINED_SECTOR_ 
W ORKLOAD_MEASURES  Table,  the  WORKLOADJTHRESHOLDS  Tables,  and 
the  values  of  the  display  options. 

The  components  of  Supervisor  Requests  subfunction  are  as 
follows: 

•  Workload  Evaluation 

•  Threshold  Request 

•  Display  Features 

No  calling  sequence  is  specified  for  this  subfunction.  These 
components  operate  independently  of  each  other.  Figure  4-13 
illustrates  the  association  of  the  components  with  the  Super¬ 
visor  Requests  subfunction. 

4.2.1  Workload  Evaluation  Component 

4. 2. 1.1  Mission 

The  Workload  Evaluation  component  performs  the  final  calcula¬ 
tions  of  the  workload  measures,  applies  the  weighting 
coefficients,  and  computes  the  overall  workload  values  for  the 
sectors  in  the  area  or  the  sector(s)  requested.  The  component 
is  activated  either  directly  by  the  supervisor,  with  an 
Immediate  Mode  Request,  or  automatically,  by  SWP,  at  periodic 
intervals,  following  a  Conditional  Mode  Request. 

4 . 2. 1.2  Design  Considerations  and  Component  Environment 

The  sectorization  schedule  that  is  in  effect  over  the  display 
time  horizon  is  considered  by  this  component.  If  a  new 
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FIGURE  4-13 

SUPERVISOR  REQUESTS  SUBFUNCTION 
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sectorization  plan  becomes  effective  during  a  time-interval, 
then  the  workload  values  are  calculated  for  the  sectorization 
plan  which  is  active  the  larger  percent  of  the  time  for  that 
time-interval. 

Input 

Input  data  for  the  Workload  Evaluate.:  component  contain  both 
global  and  shared  local  tables  and  parau  ters.  The  global  data 
for  this  component  consist  of  the  following  which  are  described 
in  "Data  Specification  for  AERA  1.0"  [Vol.  5]: 

•  BASI C_SECT0R_W0RKL0AD_MEASURES 

•  Sectorization  Plan  (SECT0RI2ATI0N_PLAN) 

•  Sectorization  Schedule  (SECTORIZATION_SCHEDULE) 

•  Display_Time_Horizon 

•  Time_Interval_Duration 

•  Cell_Density_Ratio 

•  Aircraft  Count  Coefficient  (Ac_Coefficient) 

•  Flight  Plan  Conflict  Coefficient  ( Flight  JPlan_Cfl_ 

Coefficient) 

•  Airspace  Coefficient  (AirspacejCfljCoefficient) 

•  Pa_Coefficients 

•  DensityjCoefficient 

The  shared  local  data  for  this  component  include  the  following 
tables  and  parameters  described  in  Appendix  A. 

•  Cell  Density  Airspace  Grid  (CELL_DENSITY) 

•  Block  Density  Airspace  Grid  (BL0CK_DENSITY) 

•  Organization  Type  (Organ_Type) 

•  Li8t_0f_Sectors 

•  Area_Name 

•  Aircraft  Count  Option  (Ac_Count_Cption) 

•  Weighted_Pa_Option  ~ 

•  Density_Option 

•  Overall_Workload_Option 

•  .  DisplayJTime_Interval8 

Output 

The  outputs  are  the  five  workload  measures  according  to  sector 
and  time-interval,  as  shown  in  Section  3. *1.2. 2.  Depending  on 
the  value  of  the  organization  type  variable,  these  measures  are 
output  in  either  the  BASIC_SECTOR_WORKLQAD_MEASURES  Table  or 
the  COMBINED  SECTOR  WORKLOAD  MEASURES  Table. 
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4 .2.1.3  Component  Design  Logic 
Workload  Evaluation 


The  Workload  Evaluation  component  processes  data  only  for  the 
specified  measure(s),  time  interval(s)  and  sector(s). 

As  Figure  4-14  illustrates,  the  Workload  Evaluation  component 
tests  whether  the  output  is  associated  with  an  organization 
type  (OrganJType)  of  sector  or  area.  If  the  OrganJType  is 
*  SECTOR, *  then  the  Calculate  Basic  Sector  Workload  element  is 
invoked  for  each  sector  in  List_of_Sectors.  However,  if  the 
OrganJType  is  ’AREA,1  then  the  Calculate  Area  Workload  element 
is  invoked.  The  Workload  Evaluation  component  contains  the 
following  elements  which  are  called  in  sequence  depending  upon 
whether  the  Calculate  Basic  Sector  Workload  element  or  Cal¬ 
culate  Area  Workload  element  is  invoked: 

Calculate  Basic  Sector  Workload 
Compute  Basic  Sector  Density 
Compute  Unit  Density  Sum 

Compute  Percent  of  Aircraft 
Calculate  Area  Workload 

Compute  Basic  Sector  Density 
Compute  Combined  Sector  Calculations 

The  workload  measures  may  be  adjusted  (if  the  supervisor  speci¬ 
fies)  by  the  adaptation  factors. 

Calculate  Basic  Sector  Workload 


The  Calculate  Basic  Sector  Workload  element,  shown  in 
Figure  4-15,  computes  the  workload  on  one  sector  for  the  dis¬ 
play  time-intervals  requested.  For  each  appropriate  record  in 
the  BASIC_SECTCR_WORKLOAD_HEASURES  (BSWM)  Table,  the  options  on 
various  workload  measures  are  tested  to  determine  if  their 
workload  values  need  to  be  computed.  If  the  value  of  the  over¬ 
all  workload  measure  is  computed,  then  the  values  of  other 
measures  are  automatically  computed.  Finally  the  values  of 
these  workload  measures  are  updated  in  the  BSWM  Table. 

The  main  portion  of  the  calculations  fqr  the  density  measure  is 
contained  in  three  elements — Compute  Basic  Sector  Density,  Com¬ 
pute  Unit  Density  Sum  and  Compute  Percent  of  Aircraft.  These 
elements  are  described  in  Figure  4-16,  4-17,  and  4-18. 

The  cell  density  airspace  grid  and  the  block  density  airspace 
grid  contain  the  aircraft  count  for  density  on  the  cell  level 
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ROUTINE  Workload  Evaluation; 

REFER  TO  GLOBAL  BASIC_SECTOR_WORKLOAD_MEASURES  OUT,  COMBINED_SECTOR 
WORKLOAD  MEASURES  OUT; 

REFER  TO  SHARED  LOCAL  List_Of_Sectors  IN; 

DEFINE  VARIABLES 

I  Index 

Basic_Sector_Number  Basic  sector  id  for  sector  to  be  displayed; 
IF  Organ_Type  E(£  ’SECTOR’ 

THEN 

FOR  I  -  1  TO  COUNT  (Ust_Of_Sectors); 

Basic_Sector_Number  ■  Ust_Of_Sectors(I); 

CALL  Calculate_Basic_Sector_Workload  (Basic_Sector_Number 
IN); 

ELSE  #it  is  an  ’AREA’# 

CALL  Calculate_Area_Workload; 

END  Workload  Evaluation;  ~ 


FIGURE  4-14 
WORKLOAD  EVALUATION 
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ROUTINE  Calculate_Basic_Sector_Workload; 

Icalculate  for  one  basic  sector# 

PARAMETERS  Basic  Sector  Number  IN; 

REFER  TO  GLOBAL  BASIC_SECTOR_WORKLOAD_MEASURES  INPUT,  Display_Time_ 
Horizon  IN,  Time_Interval_Duration  IN;  PajCoefficients  IN,  Cell_ 
Den8ity_Ratio  IN,  AcjCoefficient  IN,  Flight_Plan_Cfl_Coefficient 
IN,  Airspace_Coefficient  IN,  DensityjCoefficient  IN; 

REFER  TO  SHARED  LOCAL  Ac_Count_Option  IN,  Weight ed_Pa_Option  IN, 
Density_Option  IN,  Overall_Workload_Option  IN,  Di8play_Time_ 
Intervals  IN; 

DEFINE  VARIABLES 


Ba  8 ic_Se  ct or_Number 
Cell_Density_Value 
Block_Density_Value 
Den 

Ac_Count 

Wpa 

Overall 


Basic  sector  number  for  sector  to  be 
displayed 

Sum  of  percent  of  aircraft  for  cell 
density  for  sector  time  interval 
Sum  of  percent  aircraft  for  block 
density  for  sector  time  interval 
Density  value  for  sector  time  interval 
being  processed 

A  value  of  the  average  number  of 

aircraft  for  the  sector  time  interval 
being  processed 

Weighted  combined  pa  value  for  sector  time 
interval  being  processed 
Overall  workload  value  for  sector  time 
interval  being  processed; 


FIGURE  4-15 

CALCULATE  BASIC  SECTOR  WORKLOAD 
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REPEAT  FOR  EACH  BASIC_SECTOR_WORKLOAD_MEASURES  (BSWM)  RECORD 

WHERE  (BSWM.sector_number  EQ  Basic_Sector_Number)  AND  (BSWM.time_ 
interval_id  indicates  that  the  time  is  in  the  Display_Time_ 
Intervals  and  is  also  between  the  current  time  and  the  Display_ 
Time_Horizon); 

Wpa  =  0; 

Den  *  lj 
Overall  =0; 

Ac_Count  =  Oj 

IF  (Density_Option  E£  TRUE)  OR  (Overall_Workload_Option  E£  TRUE) 
THEN  #compute  density# 

CALL  Compute_Basic_Sector_Density  (Cell_Density_Value  OUT, 
Block_Denslty_Value  OUT,  Basic_Sector_Number  IN); 

Den  “  Cell_Density_Ratio  *  ( (Cell_Density  Value/3  -  0.283)/(l  - 
0.283))  +  (1  -  Cell  Denslty_Ratio)  *  (TBlock_Density  Value/3 
-  0.283)/ (1  -  0.2837); 

IF  (Ac_Count_0ption  E(£  TRUE)  OR  (Overall_Workload_Option  E^  TRUE) 
THEN  #compute  average  aircraft  count# 

Account  -  BASIC_SECTOR_WORKLOAD_MEASURES.total_fl_time/Time_ 
Interval_Dura tion ; 

IF  (Weighted_Pa_Option  E£  TRUE)  OR  (Overall_Workload_Option  EQ 
TRUE) 

THEN  ^compute  weighted  planned  action  value# 

Wpa  -  SUM  (BASIC_SECTOR_WORKLOAD_MEASURES.pa_counts  *  Pa_ 
Coefficients) ; 

IF  Overall_Workload_Option  E^  TRUE 
THEN  #compute  overall  workload# 

Overall  -  Ac_Count  *  Ac_Coefficient  +  BASIC_SECT0R_W0RKL0AD_ 
MEASURES. fp_conflict_count  *  Flight_Plan_Cfl_Coefficient  + 
BASIC_SECTOR_WOEKLQAD_MEASURES .airspace_conf lict_count  * 
Airspace_Cfl_Coefficient  +  Wpa  +  Den  *  Density_Coefficient; 
UPDATE  IN  BASIC_SECTOR_WORKLQAD_MEASURES  (aver_aircraf t_count  - 
Ac__Count ,  weighted  pa  *  Wpa,  density  ■  Den,  overall_workload_ 
measures  “  Overall); 

END  Calculate_Ba8ic_Sector_Workload; 


FIGURE  4-15 

CALCULATE  BASIC  SECTOR  WORKLOAD  (Concluded) 
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ROUTINE  Coinpute_Basic_Sector_Density; 

PARAMETERS  Cell_Densit'y_Value  OUT,  Block_Density_Value  OUT,  Basic_ 
Sector_Number  IN; 

REFIR  TO  GLOBAL  Time  Interval  Duration  IN; 

REFER  TO  SHARED  LOCAL  CELL  DENSITY  IN,  BLOCK  DENSITY  IN,  DELTA  T  IN 
DEFINE  VARIABLES 

Cell_Denslty_Value  Sum  of  percent  of  aircraft  for  cell 

density  for  sector  time  interval" 
Block_Density_Value  Sum  of  percent  of  aircraft  for  block 

density  for  sector  time  interval 
Basic_Sector_Number  Basic  sector  being  processed 
Tot_Ac_Count  Total  number  of  aircraft  in  the  sector 

time  interval 

Start_Cell_Time  Beginning  time  associated  with  time 

division 

J  Index; 

DEFINE  TABLES 

UNITJD  Table  for  unit  of  cells  or  blocks 

unitjld  Cell  or  block  identifier 

aircraft_count  Number  of  aircraft  in  the  unit; 


FIGURE  4-16 

COMPUTE  BASIC  SECTOR  DENSITY 
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//Compute  density  on  cell  level;  UNIT_D  used  for  cells// 

Tot_Ac_Count  =  0; 

//Step  through  time  divisions  in  intervals// 

FOR  J  =1  TO  Tlme_Interval_Duration/Delta_T; 

Start_Cell_Time  15  the  time  at  the  beginning  of  time  division  J; 
#Step  through  cells  in  sector  and  add  the  number  of  aircraft  in# 
#each  cell  to  the  total// 

REPEAT  FOR  EACH  CELLJDENSITY  RECORD 

WHERE  (CELL_DENSITY.sector_number  EQ  Basic_Sector_Number)  AND 
(CELL_DENSITY.beg_time  E£  Start_Cell_Time); 

IF  J  EQ  1 

THEN  "" #this  is  the  first  time  division// 

INSERT  INTO  UNIT  D  (unitjtd  -  CELL_DENSITY. cellJLd , 
aircraft_count  “  CELL_DENSITY. aircraf t_count); 

#Otherwise,  add  the  number  of  aircraft  in  the  cell  tc  the  saved# 
#number  for  that  cell# 

ELSE 

UPDATE  IN  UNITJD  (aircraft_count  =  aircraft_count  +  CELL_ 
DENSITY . aircraf t_coun t ) 

WHERE  UNIT _D . unit_id  EQ  CELL_DENSITY. cell_id ; 

Tot_Ac_Count  “  Tot_Ac_Count  +  CELL_DENSITY. aircraf tjcount; 

CALL  Compute_Unit_Density_Sum  (Cell_Density_Value  OUT,  Tot_Ac_Count 
IN,  UNIT_D  IN); 

DELETE  FROM  UNIT_D;  #delete  entire  table  to  use  again# 

#Compute  density  on  block  level;  UNIT_D  used  for  block  density# 
Tot_Ac_Count  “  0; 

FOR  J  “  1  TO  Time_Interval_Duration/Delta_T; 

Compute  Start_Cell_Time  for  time  division  J; 

REPEAT  FOR  EACH  BLOCK_DENSITY  RECORD  #each  block  in  sector# 

WHERE  (BLOCK_DENSITY.sector_number  Basic_Sector_Number)  AND 
(BLOCK  DENSITY. beg  time  EQ  Start  Cell  Time); 

IF  J  E£  1 
THEN 

INSERT  INTO  JNIT_D  (unit_id  »  BLOCK_DENSITY.block_id, 
aircraf  t_count  ■  BL0CK_DENSITY . aircraf  t_count ) ; 

ELSE 

UPDATE  IN  UNIT_D  (aircraf  t_count  M  aircraf  t_count  +  BL0CK_ 
DENSITY. aircraf  t_count) 

WHERE  UNIT_D. unitjtd  E^  BLOCK_DENSITY.block_id; 
Tot_Ac_Count  **  Tot_Ac_Count  +  BL0CK_DENSITY. aircraf t_count; 

CALL  Compute_Unit_Density_Sum  (Block_Density_Value  OUT,  Tot_Ac_Count 
IN,  UNIT_D  IN);  ‘ 

END  Compute_Basic_Sector_Density; 


FIGURE  4-16 

COMPUTE  BASIC  SECTOR  DENSITY  (Concluded) 
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ROUTINE  Compute_Unit_Density_Sum; 

PARAMETERS  Sum_Per_Ac  OUT,  Tot_Ac_Count  IN,  UNIT_D  IN; 

DEFINE  VARIABLES 
PerjCellJCnv 

Per_Ac 
Sum_Per_Ac 
Tot_Ac_Count 
Tot_NojCells 
CelljCount  (*) 

DEFINE  TABLES 
UNIT_D 
unit_id 

aircraf  t_count  Number  of  aircraft  in  the  unit; 

SELECT  FIELDS  aircraf t_count 
FROM  UNIT_D 

INTO  Cell_Count  #local  array# 

RETURN  COUNT  (Tot_No_Cells) 

ORDER  BY  aircraf  t_count;  #decreasing  order# 

Per_Cell_Inv  ■  10;  #PerjCell  is  10%# 

CALL  Compute_Percent_Of_Aircraft  (Per_Cell_Inv  IN,  Per_Ac  OUT, 
CelljCount  IN,  Tot_No_Cells  IN,  Tot_Ac_Count  IN); 

Sum_Per_Ac  “  Per_Ac; 

Per__Cell_Inv  ■  4;  #Per_Cell  is  25%# 

CALL  Compute_Percent_Of_Aircraft  (Per_Cell_Inv  JN,  Per_Ac  OUT, 
CelljCount  IN,  Tot_No_Cells  IN,  Tot  Ac  Count'  IN); 

Sum_Per_Ac  ■  SumJPer  Ac  +  Per_Ac; 

Per_Cell_Inv  ■  2;  7Per_Cell  is  50%# 

CALL  Compute_Percent_Of_Aircraft  (Per_Cell_Inv  IN,  Per_Ac  OUT, 
CelljCount  IN,  Tot_No_Cells  IN,  Tot_Ac_Count  IN); 

Sum_Per_Ac  *  Sum_Per_Ac  +  Per_Ac; 

END  Compute_Unit_Den8ity_Sum; 


Inverse  of  Per_Cell  (proportions  of  sector's 
cells  with  the  greatest  number  of  aircraft) 
Percent  of  aircraft  corresponding  to  Per_Cell 
Accumulated  sum  of  Per_Ac 
Number  of  aircraft  in  the  sector 
Total  number  of  cellB  in  sector 
Array  of  the  number  of  aircraft  in  each  cell  in 
the  sector; 

Table  for  unit  of  cells  or  blocks 
Cell  or  block  identifier 


FIGURE  4-17 

COMPUTE  UNIT  DENSITY  SUM 
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ROUTINE  Compute_Percent_Of_Aircraf t; 

PARAMETERS  Per_Cell_Inv  IN,  Per_Ac  OUT,  Cell_Count  IN,  Tot_No_Cells 
IN,  Tot_Ac_Count  IN; 

DEFINE  VARIABLES 

PerjCe.ll_Inv  Inverse  of  PerjCell  (proportions  of  sector’s 

cells)' 

PerjAc  Percent  of  aircraft  corresponding  to  PerjCell 

AcjCount.  Number  of  aircraft  contained  in  PerjCell 

Tot^Ac_Count  Number  of  aircraft  in  the  sector 

NojCells  Number -of  cells  in  sector  to  be  processed 

Tot_No_Cells  Total  number  of  cells  in  sector 

Remainder  Remainder  from  Tot_No_Cells  divided  by  Per_ 

Cell_Inv 

CelljCount  (*)  Array  of  the  number  of  aircraft  In  each  cell  in 

the  sector 

J  Index; 

Ac_Count  *  0; 

Remainder  *  MOD(Tot_No_Cells,  Per_Cell_Inv) ;  #M0D  is  a  bulltin# 
Ifunction? 

NojCells  “  CEIL (Tot  No  Cells/Per  Celllnv) ;  #CEIL  is  a  bulltin# 
#function? 

FOR  J  -  1  TO  No_Cells; 

IF  J  E£  NojCells 
THEN 

Ac_Count  *  AcjCount  +  Cell__Count(J)  *  (Remainder/ PerjCell__ 
Inv  ); 

ELSE 

Ac_Count  *  Ac_Count  +  CelljCount  (J); 

Per_Ac  "  AcjCount/Tot_Ac_Count; 

END  Compute_Percent_Of_Aircraft; 


FIGURE  4-18 

COMPUTE  PERCENT  OF  AIRCRAFT 
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and  block  level  respectively..  The  density  measure  considers 
both  the  cell  level  and  the  block  level  from  two  perspectives 
to  produce  one  density  value  for  the  sector  and  time- 
intervals.  The  density  measure  is  a  number  which  has  a  minimum 
value  of  0.0  when  the  aircraft  population  is  uniformly 
distribute  or  scattered  over  a  sector's  cells  and  maximum  value 
of  1.0  when  all  traffic  is  concentrated  in  a  single  cell. 

Figure  4-19  is  provided  to  illustrate  the  density  calculations 
of  the  Calculate  Basic  Sector  Workload  element  and  of  the 
Compute  Basic.  Sector  Density  element.  Uniform,  scattering, 
moderate  clustering.,  and  extreme  clustering  cases  are  shown  for 
a  given  sector  and  time-interval.  The  cell  aircraft  occupan¬ 
cies  accumulated  .over  the  divisions  of  .  a  time-interval  are 
presented.  The  adjacent  graphs  show  the  cumulative  percent  of 
aircraft  occupying  the  cells  starting  with  tne  most  dense 
cells.  The-  corresponding  values  of  the  percent  of  the  sector's 
occupancies  are  also  indicated. 

The  density  measure  combines  the  three  values  of  the  percent  of 
the  sector's  occupancy  for  both  the  cell  and  block  level.  The 
average  of  these  three  values  is  normalized.  The  result  for 
the  cells  is  weighted  by  the  Cell  Density  Ratio  and  that  for 
the  blocks  is  weighted  by  1.0-Cell  Density  Ratio.  The  weighted 
sum  (ranging  between  0.0  and  1.0)  is  the  value  of  the  density 
measure.  In  summary,  for  the  Calculate  Basic  Sector  Workload 
element,  density  is  calculated  as  the  following: 

Cell_Density_Ratio*( (Cell  Density_Value/ 3-0 .283)/ (1-0 .283) ) 

+  (l-Cell_Density_Ratio)*T(Block_Density_yalue/ 3-0.283)/ 
(1-0.283) 

The  constant  0.283  is  the  average  percent  of  the  sector’s  occu¬ 
pancy  in  the  uniform  case  (i.e.,  0.283  =  (0.10  +  0.25  + 
0.50)/3).  The  average  percent  of  the  sector's  occupancy  on  the 
cell  level  is  equal  to  Cell_Density_Value/divided  by  3. 

The  Cell  Density  Ratio  is  a  parameter  that  varies  from  center 
to  center.  For  centers  with  small,  densely-populated  sectors 
(such  as  those  covering  the  northeast  US),  density  is  better 
measured  using  the  cell  level.  The  blocks  are  few  in  number 
and  may  tend  to  smooth  out  small-scale  traffic  clustering  pat¬ 
terns  significant  to  the  density  workload  measure.  For  these 
centers,  the  value  of  Cell  Density  Ratio  should  be  set  close  to 
1.0.  For  centers  with  large,  sparsely-populated  sectors  (such 
as  those  covering  the  western  mountains) ,  density  is  better 
measured  using  the  block  level.  In  such  centers,  the  cells  are 
numerous,  with  typical  populations  of  0  or  1  aircraft.  These 
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Grid-Occupancy  Pattern 
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Three  types  of  clustering  are  illustrated  on  the  left:  uniform  scat¬ 
tering,  moderate  clustering,  and  extreme  clustering..  The  adjacent  graphs 
show  the  cumulative  percent  of  traffic  occupying  the  cells  starting  with 
the  most  dense  cells.  The  density  value  is  listed  which  is  based  on  the 
values  of  percent  of  cells  and  percent  of  traffic  indicated  on  the  graph. 


FIGURE  4-19 

TYPES  OF  CLUSTERING  FOR  THE  DENSITY  MEASURE 
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cells  may  be  unable  to  reflect  large-scale  traffic  clustering 
patterns  significant  to  the  density  workload  measure.  For 
theee  centers,  the  value  of  Cell  Density  Ratio  should  be  set 
close  to  0.0. 

Compute  Basic  Sector  Density 

In  the  Compute  Basic  Sector  Density  element,  the  cell  density 
value  and  the  block  density  value  are  computed  for  each  time- 
interval  being  processed.  The  logic  for  computing  the  cell 
density  value  and  the  block  density  value  are  similar;  there¬ 
fore,  only  the.  logic  for  computing  the  cell  density  value  is 
described  below.  For  one  time-interval,  the  records  in 
CELL_DEMSITY  are  examined  for  each  time  division  of  the  time- 
interval  and  for  those  records  in  the  basic  sector.  The 
aircraft  count  for  each  record  (cell)  is  incremented  in  a  local 
table  UNIT_D  which  contains  the  aircraft  count  for  each  cell. 
The  total  number  of  occupancies  in  a  sector  is  also  accumula¬ 
ted.  This  number  is  generally  greater  than  the  number  of 
aircraft:  in  a  sector. 

Compute  Unit  Density  Sum 

After  all  these  cells  have  been  processed  for  the  time- 
interval,  the  Compute  Unit  Density  Sum  element  is  called. 
First,  the  cell  occupancy  counts  in  UNIT_D  are  arranged  from 
the  highest  to  the  lowest  in  a  local  array  (CelljCount) .  The 
most  dense  10%,  25%,  and  50%  of  the  cells  are  used  to  compute 
corresponding  values  of  the  percent  of  the  sector's  occupancy. 
The  values  of  the  percent  of  the  sector's1  occupancies  represent 
various  degrees  of  density  from  uniform  scattering  to  extreme 
clustering.  In  the  most  uniform  case,  for  values  of  the  10%, 
25%,  and  50%  of  the  cells,  the  corresponding  values  of  the  per¬ 
cent  of  the  sector’s  occupancies  are  10%,  25%,  and  50%, 
respectively.  In  the  most  extreme  case,  where  all  occupancies 
are  in  a  single  cell,  the  values  of  the  percent  of  sector's 
occupancies  will  be  100%,  100%,  and  i00%,  respectively. 

Compute  Percent  of  Aircraft 


The  percent  of  the  sector's  occupancy  is  computed  by  the  Com¬ 
pute  Percent  Of  Aircraft  element  and  added  to  the  sum  of  the 
percent  of  sector's  occupancies  (Cell_Density_Value).  The  Com¬ 
pute  Percent  Of  Aircraft  element  uses  linear  interpolation,  if 
necessary,  to  compute  the  percent  of  sector's  occupancies. 
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Calculate  Area  Workload 


If  the  workload  of  an  area  is  to  be  evaluated,  then  the  logic 
in  Calculate  Area  Workload  shown  in  Figure  4-20  is  invoked  by 
the  Workload  Evaluation  component.  Under  each  sectorization 
plan  in  effect  over  the  display  time  intervals,  the  workload 

for  each  basic  sector  is  combined  by  time-intervals  and  added 
to  the  workload  for  the  respective  combined  sectors  in  the 
COMBINED_SECTORJfORKLOAD_MEASUEES  (CSWM)  Table..  If  the  super¬ 
visor  specifies  to  display  the  density  measure  or  the  overall 
workload  measure,  then  the  Compute  Basic  Sector  Density  element 
(Figure  4-16)  is  called.  Ihe  logic  of  this  element  is  des¬ 
cribed  above  in  this  section. 

Compute  .Combined  Sector  Calculations 

After  all  basic  sectors  have  been  processed,  for  a  time- 
interval',  the  Compute  Combined  Sector  Calculations  is  invoked. 
Figure  4-21  depicts  the  processing  of  the  Compute  Combined  Sec¬ 
tor  Calculations  element.  Each  combined  sector  in  the  CSWM 
Table  for  the  given  time-interval  is  processed.  The  options 
for  the  workload  measures  of  average  aircraft  count,  weighted 
planned  actions,  density,  and  overall  workload  are  tested  to 
determine  if  the  workload  values  of  these  measures  arc  to  be 
displayed.  Note  in  Figure  4-21  the  similarity  in  the  density 
equation  for  a  combined  sector  to  that  for  a  basic  sector  given 
in  Figure  4-15.  Ihe  difference  is  that  for  combined  sectors 
the  average  percent  of  the  sector's  occupancy  of  cells  Is  equal 
to  the  sum  of  the  percent  of  the  sector's  occupancy  divided  by 
the  product  of  3  and  the  number  of  basic  sectors  in  this  com¬ 
bined  sector,  instead  of  division  by  3  only  for  a  basic 
sector.  After  the  values  of  the  desired  workload  measures  are 
computed,  they  are  updated  in  the  CSWM  Table. 

4.2.2  Threshold  Request  Component 

4. 2. 2.1  Mission 


The  supervisor  can  input  a  Conditional  Mode  Request — that  is, 
request  to  be  notified  when  a  workload  measure  for  a  given 
sector  has  crossed  a  threshold.  This  is  the  purpose  of  the 
Threshold  Request  component.  The  supervisor  enters  the  sector 
identification,  the  workload  measure  identification  and  the 
threshold  value. 
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ROUTINE  CaIculate_Area_Workloadj 

REFER  TO  GLOBAL  BASIC_SECTOR_WORKLOAD_MEASURES  IN,  SECTORIZATION_PLAN 
IN,  SECTORIZATION_SCHEDULE  IN,  Display_Time_Horizon  IN,  COMBINED_ 
SECTORJWORKLOADJMEASURES  OUT; 

REFER  TO  SHARED  LOCAL  Area_Name  IN,  Ac_Count_Option  IN,  Welghted_Pa_ 
Option  IN,  Density_Option  IN,  Overall_Workload_Option  IN,  Display_ 
Time_Intervals  IN; 

DEFINE  VARIABLES 

Time_Interval_Id  Time  interval  being  processed 
Cell_Density__Value  sum  of  percent  of  aircraft  for  cell 

density  for  sector  time  interval 
Block_Den8lty_Value  Sum  of  percent  aircraft  for  block 

density  for  sector  time  interval 
Time_Interval  Index 

No_Time_Intervals  Number  of  time  intervals  to  be  output 

for  SectorizationJSchedule,  Display_  Time 
Horizon  and  requested  intervals; 

#  # 

#  In  this  routine,  for  purposes  of  clarity  and  simplicity,  the  # 
#following  abbreviation  is  used:  # 

#BSWM  for  BASIC  SECTOR  WORKLOAD  MEASURES# 


FIGURE  4-20 

CALCULATE  AREA  WORKLOAD 
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REPEAT  FOR  EACH  SECTORIZATION  SCHEDULE  RECORD 

WHERE  SECTOR! ZATION_SCHEDULE. area  E£  Area_Name  AND  SECTORIZATION_ 
SCHEDULE. time  is  associated  with  the  Display_Time_Horizon  and 
the  Display_Time_Intervals; 

Count  number  of  time  intervals  to  be  output  for  this 

SECTORIZATION_SCHEDULE  record  and  assign  to  NoJTime_Intervals; 
FOR  Time_Interval  =  1  TO  No_Time_Intervalsj 

Compute  Time_Interval_Id  associated  with  the  Time_Interval; 

REPEAT  FOR  EACH  SECTORIZATIONJPLAN  RECORD 

#Step  through  basic  sectors  in  this  area  under  this  plan# 

WHERE  SECTORIZATION_PLAN.plan_type  E£  SECT0R1ZATI0N_SCHEDULE. 
plan_type  AND  SECTORIZATION_PLAN.area_name  EQ 
SECTORIZATION_SCHEDULE. area_name ; 

INSERT  INTO  COMBINED_SECTOR_WORKLOAD_MEASURES  (sector_number 
“  SECTORIZATIONJPLAN. combined_sectorjiumber,  time_ 
interval_id  =  Time_  Interval_Id,  all  other  fields  assigned 
value  of  0); 

#Pick  out  info  for  this  sector  during  this  interval# 

REPEAT  FOR  EACH  BASIC  SECTOR  WORKLOAD  MEASURES  (BSWM)  RECORD 
WHERE  BSWM . s ector  jiumber  E£  SECTORIZATION  PLAN.basic_ 
sector_number  AND  BSWM. time_interval_id  EQ  Time_ 
Interval_Id; 

IF  (Density_Option  EQ  TRUE)  OR  (Overall_Workload_Option  EQ 
TRUE) 

'  THEN 

CALL  Compute  Basic_Sector  Density  (Cell  Density  Value 
0UT»  Bio cTc_Dens it y_Value  OUT,  SECTORlZATIONjLAN. 
basic  sectorjaumber  IN) ; 

ELSE 

Cell_Density_Value  «  0;  Block_Density_Value  *  0; 

UPDATE  IN  COMBI NED_SECT0R_W0RKL0AD_MEASURES  (CSWM)(total_ 
fl_time  *  total_fl_time  +  BSWM.total_fl_time,  fp_ 
conflict_count  ■  fp_conflictjcount  +  BSWM.fp_conflict_ 
count,  airspace_conflict__count  *  airspace_conflict_ 
count  +  BSWM. air space_jconflict_count,  pa_counts  "  pa_ 
counts  +  BSWM.pa_count8,  cell_density_value  =  cell_ 
density_value  +  Cell__Density_Value,  block_density_value 
**  block_density_value  +  Block_Density_Value,  sector_ 
count  M  sector_count  +  1) 

WHERE  CSWM. sectorjaumber  E£  SECTORIZATIONJPLAN. 

combined_sectorjaumber  AND  CSWM.time_intervalJLd  EQ 
Time_Interval_Id ; 

CALL  Compute__Combined_SectorjCalculations  (TimeJ[nterval_Id  IN); 
END  Calculate_Area_Workload; 

FIGURE  4-20 

CALCULATE  AREA  WORKLOAD  (Concluded) 


ROUTINE  Compute  Combined  Sector  Calculations; 

PARAMETERS  Time_Interva.l_Id  IN; 

REFER  TO  GLOBAL  PajCoefficients  IN,  Density_Coefficient  IN,  Airspace_ 
Cfl_Coefficient  Hi,  Flight_Plan_Cfl_Coefficient  IN,  AcjCoefficient 
IN,  Time_Interval_Duration  IN,  Cell_Density_Ratio  IN,  COMBINED 
SECTOR_WORKLOAD_MEASURES  INPUT; 

REFER  TO  SHARED  LOCAL  Weight ed_Pa_Option  IN,  Density_Option  IN, 
Overall_Workload_Option  IN,  Ac_Count_Option  IN; 

DEFINE  VARIABLES 


Wpa 

Den 

Overall 

Ac_Count 

Time  Interval  Id 


Value  of  weighted  planned  actions  for 
member  sector  and  time  interval  being 
processed 

Value  of  density  for  member  sector  and 
time  interval  being  processed 
Value  of  overall  workload  for  member 

sector  and  time  interval  being  processed 
Number  of  aircraft  for  member  sector 
and  time  interval  being  processed 
Identifier  of  time  interval  being 
processed; 


#  # 
#  In  this  routine,  for  purposes  of  clarity  and  simplicity,  the  # 

#  following  abbreviation  is  used:  if 

#CSWM  for  COMBINED  SECTOR  WORKLOAD  MEASURES# 


FIGURE  4-21 

COMPUTE  COMBINED  SECTOR  CALCULATIONS 


REPEAT  FOR  EACH  COHBINED_SECTOR_WORKLOAD_MEASURES  (CSWM)  RECORD 
WHERE  CSWM.time_interval_id  E^  Time_Interval_Id; 

Wpa*  0; 

Den  *  0; 

Overall  =  0; 

Ac_Count  =  0; 

IF  (Ac_Count_Option  E£  TRUE)  OR  (Overall_Workload_Option  E^  TRUE) 
THEN 

Ac_Count  *  COMBINED_SECTOR_WORKLOAD_MEASURES.total_fl_time/ 
Tine_Interval_Duration; 

IF  (Welghted_Pa_Option  EQ  TRUE)  OR  (Overall_Workload_Option  EQ 
TRUE) 

THEN 

Wpa  «  SUM  (COMBINED_SECTOR_WORXLOAD_MEASURES.pa_counts  * 
pa_Coefficients);  *” 

IF  (Density  Option  EQ  TRUE)  OR  (Overall  Workload  Option  EQ  TRUE) 
THEN 

Den  *  Cell_Density_Ratio  *  ((CSWM.cell_density_value/(3  *  CSWM. 
sector_count))  -  0.283)/(l  -  0.283)  +  (1  -  Cell_Density_Ratio) 

*  ((CSWM.block_density_value/(3  *  CSWM.sector_count))  - 
0.283)/ (1  -  0.283); 

IF  Overall  Workload_Option  EQ  TRUE; 

THEN. 

Overall  "  Ac_Count  *  Ac_Co efficient  +  CSWM.fp_conflict_count 
*  Flight_Plan_Cfl_Coefficient  +  CSWM. airspace_conf lie t_ 
count  *  Airspace_Cfl_Coefficient  +  Wpa  +  Den  *  Density_ 
Coefficient; 

UPDATE  IN  COMBINED_SECTOR_WORKLOAD_MEASURES 
"  #in  same  record  under  repeat# 

(overall_workload_measure  *  Overall,  aver_aircraf  t_count  m  Ac_ 
Count,  density  *  Den,  weighted_pa  ■  Wpa); 

END  Compute_Combined_Sector_Calculations; 


FIGURE  4-21 

COMPUTE  COMBINED  SECTOR  CALCULATIONS  (Concluded) 
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4, 2, 2. 2  Design  Considerations  and  Component  Environment 


Input 

The  input  data  to  this  component  are  the  following: 

•  Frequency-of-testing  parameter  (PeriodicJFrequency) 

•  Sector(s),  workload  measure(s)  and  threshold(s)  to  test 
(W0RKL0AD_THRESH0LDS ) 

The  frequency-of-testing  parameter  is  used  to  determine  the 
frequency  for  testing  of  the  workload  measure(s)  against  the 
threshold  value(s). 

Output 

The  output  requested  for  the  specified  sector(s)  is  displayed 
with  the  workload  measure(s)  and  time-interval(s).  The  output 
is  identified  with  respect  to  the  threshold  which  was  crossed 
and  to  the  fact  that  it  is  a  response  to  a  Conditional  Mode 
Request. 

Error  Conditions 


The  logic  checks  to  determine  if  another  Conditional  Mode 
Request  already  exists  for  the  same  sector  aid  workload 
measure.  The  supervisor  is  notified  of  this  situation,  if  it 
exists.  The  supervisor  then  designates  whether  to  keep  the  old 
request  and  omit  the  new  one  or  whether  to  delete  the  old 
request  and  submit  the  new  one.  An  old  request  cannot  be  auto¬ 
matically  overridden  without  the  approval  of  the  supervisor. 

4.2 .2 .3  Component  Design  Logic 

The  frequency-of-testing  parameter  specifies  at  what  times  the 
workload  output  is  computed  to  test-  against  the  active  thres¬ 
holds.  At  these  times,  the  Workload  Evaluation  component  is 
activated  for  each  sector  having  one  or  more  thresholds  to 
test.  The  outputs  are  stored  and  then  compared  with  the  thres¬ 
hold  values.  If  the  threshold  has  been  reached,  then  the 
display  message  and  output  of  the  Threshold  Request  component  is 
presented  to  the  supervisor. 
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4.2.3  Display  Features  Component 
4. 2. 3.1  Mission 


The  Display  Features  component  permits  the  supervisor  to  define 
his  own  mode  of  operation  and  to  utilize  SWP  as  he  desires. 
Some  possible  options  are  presented  in  Figure  4-22.  The  dis¬ 
play  features  provide  for  automatic  outputs,  periodic  output, 
establishment  of  thresholds,  and  options, on  the  output  tables. 

4. 2. 3. 2  Design  Considerations  a~id  Component  Environment 

Periodically,  an  automatic  Immediate  Mode  output  of  an  area  or 
a  sector  may-  be  requested' to  activate  the  Workload  Evaluation 
component *.  The  supervisor  may  specify  a  time  interval,  such  as 
five  minutes,  as  the  frequency  with  which  the  Workload  -Evalua¬ 
tion  -component  is  invoked  and  the  output  data  are  displayed. 
(Note  the  contrast  with  Conditional  Mode,  which  also  causes 
automatic  periodic  calls  to  this  component;  the  periodicity  in 
this  case  is  a  parameter,'  not  a  supervisor  input.) 

Various  options  on  the  output ,  tables,  can  be  defined.  Some  of 
these  options  are  as  follows:.  .  'i' 

v. 

•  To  sequence  the  display’ of  sector. data- in  the  area 

* 

•  To  identify  the  sectorization  plans 

•  To  define  the  display  time  horizon 

•  To  display  only  normalized  outputs  or  to  include  the 
historical  and  unnormalized  outputs  as  well 

•  •  To  select  the  workload  measures  to  display  in  the  output 
table 

•  To  select  the  output  table  format 

The  options  have  default  values.  In  addition  to  the  overall 
output  values,  these  workload  measures  may  be  displayed: 

•  Average  number  of  aircraft  at  one  time 

•  Weighted  sum  of  planned  actions 

•  Number  of  encounters  (FPCP  and  AP) 

•  Density  value 
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TIME  INTERVALS 

WORKLOAD  MEASURE:  AVERAGE  NUMBER  OF  AIRCRAFT 
10  MAY  1983  9:02  p.m. 


a)  Graph  for  One  Sector  and  One  Workload  Measure 


TIME  INTERVAL 

AVERAGE  NUMBER  OF  AIRCRAFT 

9:00-9:15 

5 

9:15-9:30 

7 

9:30-9:45 

5 

9:45-10:00 

7 

SECTOR:  ENSUE 

WORKLOAD  MEASURE:  AVERAGE  NUMBER  OF  AIRCRAFT 

10  MAY  1983  9:02  p.m. 


b)  Table  for  One  Sector  and  One  Workload  Measure 


FIGURE  4-22 

EXAMPLE  OF  INFORMATION  THAT  COULD  BE  DISPLAYED 


WORKLOAD  MEASURES 

TIME  INTERVALS 

9:00-9:15  9:15-9:30  9:30-9:45  9:45-10:00 

Average  Number  of 
Aircraf  t 

Number  of  ,FPCP 
Encounters 

Overall 

5.7  5  7 

.0  1  0  2 

312  419 330  399 

SECTOR':-  ENSUE 
10  MAY  1983  9:02  p.m. 


c)  Table  for  One  Sector  and  Multiple  Workload  Measures 


SECTORS 

TIME 

INTERVALS 

9:00-9:15 

9:15-9: 

30  9:30-9:45 

9:45-10:00 

ENSUE 

5 

7 

5 

7 

WESTMINSTER 

7 

9 

6 

7 

SWANN 

6 

8 

7 

7 

HARRISBURG 

4 

7 

7 

8 

EAST  TEXAS 

7 

8 

6 

7 

AREA:  B 

WORKLOAD  MEASURES:  AVERAGE  NUMBER  OF  AIRCRAFT 
10  MAY  1983  9:02  p.m. 


d)  Table  for  Multiple  Sectors  and  One  Workload  Measure 


FIGURE  4-22 

EXAMPLE  OF  INFORMATION  THAT  COULD  BE  DISPLAYED 

(CONTINUED) 
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SECTORS 

TIME  INTERVALS 

9:00-9:15 

9:15-9:30 

9:30-9:45 

9:45-10:00 

ENSUE 

5 1 0 1 

7 1 1 1 

5 1 0 1 

7 1 2 1 

WESTMINSTER 

1  1 

7 1 0 1 

1  1 

9 1 2 1 

1  i 

6 1 1 ! 

1  1 

7 1 0 1 

SWANN 

1  1 

6 1 0 1 

1  I 

8 1 1 1 

1  1 

7 1 1 1 

1  1 

7 1 0 1 

HARRISBURG 

IT 

4 1 0 1 

1  1 

7 1 0 1  ' 

1  1 

7  111' 

1  1 

8 1 3 1 

EAST  TEXAS 

1  1 

7 1 0 1 

1  1 

8 1 0 1 

1  1  ‘ 

6 1 0 1 

1  1 

7 1 1 1 

TT  TT  TT  IT  J 

Key 

a  1 1  b  I  c 
d  I  e  If 


AREA:  B 

WORKLOAD  MEASURES:  a,b 
10  MAY  1983  9:02  p.m. 


a.  Average  Number  of  Aircraft 

b.  FPCP  Encounter  Count 

c.  AP  Encounter  Count 

d.  Weighted  Planned  Actions 

e.  Density 

f.  Overall  Measure 


e)  Table  for  Multiple  Sectors  and  Multiple  Workload  Measures 


FIGURE  4-22 

EXAMPLE  OF  INFORMATION  THAT  COULD  BE  DISPLAYED 

(CONCLUDED) 


V 


-•j 
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The  user-system  interface  issues  play  a  major  role  in  the  devel¬ 
opment  of  the  display  features  which  have  been  presented  here  in 
general  terms. 
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APPENDIX  A 


SECTOR  WORKLOAD  PROBE  DATA 


This  appendix  supports  the  SWP  algorithm  specification.  The  data 
local  to  SWP  are  described  using  the  relational  data  model  presented 
in  the  "Data  Specifications  for  AERA  1.0”  [Vol.  5].  The  following 
data  are  described  in  this  appendix: 

•'  INDIVIDUAL_AIRCRAFT_WORKLQAD 
■  •  •  REVISED_SUBJECT_WORKLOAD 

.  •  .  ESC_INCREMENT  . 

■  ;  •  . . ESC_DECREMENT 

•  CELL_DENSITY 

•  BL0CK_DENSITY 

•  SUBJECTJCELL 

•  SUBJECT J5L0CK 

•  Parameters 

INDIVIDUAL_AIRCRAFT_WORKLOAD: 

+— - - -  - . . . . . . — - - - 

I  FL_ID  |  SECT0R_NUMBER  I  TIME_INTERVAL_ID  |  beginning_time 
+ - - - 


|  ending_time  |  total_fl_time  |  FPCP_encounter_count 


{  AP_encounter_count  |  altitude_change_pa_count 


|  altitude_change_with_restricticns_pa_count 


- j. 

|  vector_pa_count  |  speed_change_jpa_count  |  holdjpa_count  | 

- : - f- 

pajcouhts  AGGREGATE  (altitude_change_pa_count,  altitude_change_ 
with_restriction8__pa_count,  vector_j)a_count,  speed__change_pa_ 
count,  hold_pa_count) 

This  table  defines  workload  associated  with  a  flight  ID  for  a 
specific  sector  and  time-interval.  This  table  contains  a  record  for 
each  sector  and  time-interval  combination  for  the  flight  ID.  An  IAW 
Table  exists  for  each  flight  plan  which  has  been  processed. 

FL_ID  Unique  flight  identifier. 
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SECTOR_NUMBER 

Basic  sector  through  which  the  flight  passes 
in  the  time-interval  and  for  which  the 
values  in  this  record  are  computed. 

TIME_INTERVAL_ID 

Time-interval  for  which  the  values  in  this 
record  are  computed. 

beginning jtlme 

Time  when  sector-time-interval  begins. 

ending__time 

Time  when  sector-time-interval  ends. 

total_fl_time 

Total  flight  time  of  all  the  aircraft  within 
the  sector  during  the  time-interval 
specified. 

FPCP_encounter_count 

Number  of  Flight  Plan  Conflict  Probe 
encounters  for  the  flight  in  this  sector- 
time-interval. 

AP_encounter_count 

Number  of  Airspace  Probe  encounters  for  the 
flight  in  this  sector-time-interval. 

a 1 titude_chang e_ 
pa  count 

Number  of  planned  actions  of  the  type — 
change  altitude — for  the  flight  in  this 
sector-time-interval. 

altitude_change_with_ 

restrictions_pa__count 

Number  of  planned  actions  of  the  type — 
change  altitude  with  restrictions — for  the 
flight  in  this  sector-time-interval. 

vector_pa_count 

Number  of  planned  actions  of  the  type — 
vector— for  the  flight  and  sector-time- 
interval. 

speed_change_ 

pa_count 

Number  of  planned  actions  of  the  type — speed 
change — for  the  flight  and  the  sector- 
time-interval. 

hold_pa_count 

Number  of  planned  actions  of  the  type — hold 
on  route — for  the  flight  and  the  sector- 
time-interval. 

pa_counts  AGGREGATE  (altitude_ehange_pa_count,  altitude_change_ 
with_restrictions_pa  count,  vector_pa_count,  speed_changejpa_ 
count,  hold  pa  countT 
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REVISED_SUBJECT_WORKLOAD : 
H - ■ - - - - - 


|  SECTOR_NUMBER  |  TIME_INTERVAL_ID  I  beginningjtime  I  ending_time 


I  total_fl_time  I  FPCP_encounter_count 


I  AP_encounter_count  |  altitude_change_pa_count 


I  altitude__change_with__restrictions_paxount 


I  vector_pa_count  I  speed_change_pa_count  |  hold_pa_count  I 


pa_counts  AGGREGATE  (altitude_change_pa_count  >  altitude_change__ 
with_restrictiono_pa_count,  vector_pa_count,  speed_change_pa_ 
count,  hold_pa_count) 

This  table  defines  workload  associated  with  a  flight  ID  for  a 
specific  sector  and  time-interval.  This  table  contains  a  record  for 
each  sector  and  time-interval  combination  for  the  flight  ID 
currently  being  processed  in  Sector  Workload  Probe. 

SECTOR_NUMBER  Basic  sector  through  which  the  flight  passes 

in  the  time-interval  and  for  which  the 
values,  in  this  record  are  computed. 

TIHE_INTERVAL_ID  Time-interval  for  which  the  values  in  this 

record  are  computed. 

beginningjtime  Time  when  sector-time-interval  ends. 

ending_time  Time  when  sector-time-interval  begins. 

total_fl_time  Total  flight  time  of  all  the  aircraft  within 

the  sector'  during  the  time-interval 
specified. 

FPCP_encounter_count  Number  of  Flight  Plan  Conflict  Probe 

encounters  for  the  flight  in  this  sector- 
time-interval. 

AP_encounter_count  Number  of  Airspace  Probe  encounters  for  the 

flight  in  this  sector-time-interval. 
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.  altitude_change_ 
pa_count 

alt i tud e_chang  e_wi th_ 
restrictions_pa_count 

vector__pa_count 


speed_change_ 

pajeount 

hold_pa_count 


pa_count8  AGGREGATE  (altitude_change_pa_count,  altitude_change_ 
with_restriction8_jpa__count ,  vector_pa_count,  speed_change_jpa_ 
count,  hold_pa_c ount ) 


ESCJENCREMENT : 

+ - b 

I  FL_ID  |  sector_number  |  time_interval_id  I 
+ - b  . 

This  table  describes  where  the  subject  aircraft  will  have  an 
encounter.  One  record  is  located  for  each  object  aircraft  having  an 
encounter  with  the  subject. 

FL_ID  Unique  flight  identifier. 

sectorjiumber  Basic  sector  through  which  the  object  passes  in 

the  time-interval. 

time_interval_id  Time  interval  in  which  the  encounter  workload  is 

considered. 


Number  of  planned  actions  of  the  type-- 
change  altitude — for  the  flight  in  this 
sector-time-interval. 

Number  of  planned  actions  of  the  type — 
change  altitude  with  restrictions — for  the 
flight  in  this  sector-time-interval. 

Number  of  planned  actions  of  the  type — 
vector — for  the  flight  and  sector-time- 
interval. 

Number  of  planned  actions  of  the  type — speed 
change--for  the'  flight  and  the  sector-time- 
interval. 

Number  of  planned  actions  of  the  type — hold 
on  route — for  the  flight  and  the  sector- 
time-interval. 
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I  FL  ID  |  sector  number  |  time  interval. id  | 


This  table  describes  where  the  subject  would  have  had  an  encounter. 
One  record  is  found  for  each  object  aircraft  which  had  an  encounter 
with  the  subject. 

FL_ID  Unique  flight  identifier. 

sectorjaumber  Basic  sector  through  which  the  object  passes 

in  the  time-interval. 

timejintervaljLd  Time-interval  :ln  which  the  encounter 

workload  is  considered. 


CELL_DENSITY; 

H - - - - - — - - — - — - - -  — - — — 4 

I  CELL  ID  I  BEG  TIME  |  aircraft  count  |  block  id  |  sector  number  I 


This  table  contains  density  information  on  the  four  dimensional  (x, 
y,  z,  t)  airspace  cell.  The  cell  is  identified  in  the  x,  y,  z 
dimensions  by  CELL_ID  and  in  the  t  dimension  by  BEG_TIME.  The 
density  information  consists  of  the  number  of  aircraft  in  the  cell 
and  identifying  characteristics. 

CELL_ID  Unique  identifier  of  an  airspace  cell  in 

the  x,  y,  z  airspace  grid. 

BEG_TIME  Beginning  time  of  the  four  dimensional 

airspace  cell. 

aircraft  count  Number  of  aircraft  in  'the  four  dimensional 

cell. 

Unique  identifier  of  an  airspace  block  in 
the  x,  y,  z  airspace  grid.  A  block  is 
composed  of  eight  airspace  cells. 

Sector  number  of  the  basic  sector 
associated  with  this  cell. 


blockjtd 

sector  number 
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BLOCK  DENSITY: 


I  BLOCK  ID  |  BEG  TIME  |  aircraft  count  |  sector  number  I 


This  table  contains  density  information  on  the  four-dimensional  (x, 
y,  z,  t)  airspace  block.  The  block  is  identified  in  the  x,  y,  z 
dimensions  by  BL0CK_ID  and  in  the  t  dimensions  by  BEG_TIME.  The 
density  information  consists  of  the  number  of  aircraft  in  the  block 
and  the  corresponding  basic  sector. 

BL0CK_ID  Unique  identifier  of  an  airspace  block  In 

the  x,  y,  z  airspace  grid. 

BEG_TIME  Beginning  time  of  the  four-dimensional 

airspace  block. 

aircraft_count  Number  of  aircraft  in  the  four-dimensional 

block. 

sectorjaumber  Sector  number  of  the  basic  sector 

associated  with  this  block. 


SUBJECT  CELL: 


+— — . . .  >■■■  ■■  | 

I  FL_ID  |  CELL_ID  I  BEG_TIME  |  aircraf t_count  I  block_id  I 
+ - - - h 


This  table  contains  density  information  on  the  four-dimensional 
(x,y,z,t)  airspace  cell  by  subject  aircraft  FL_ID.  The  cell  is 
identified  in  the  x,  y,  z  dimensions  by  CELL_ID  and  in  the  t 
dimension  by  BEG_TIME.  The  density  information  consists  of  the 
number  of  aircraft  in  the  cell  and  identifying  characteristics. 

FL_ID  Unique  flight  identifier. 

CELL_ID  Unique  identifier  of  an  airspace  cell  in  the  x, 

y,  z  airspace  grid. 

BEGJTIME  Beginning  time  of  the  four-dimensional  airspace 

cell. 

aircraf t_count  Number  of  aircraft  in  the  four-dimensional  cell. 

block_id  Unique  identifier  of  an  airspace  block  in  the  x, 

y,  z  airspace  grid.  A  block  is  composed  of 
eight  airspace  cells. 


SUBJECT_BLOCK: 

+ - — - }■ 

I  FL  ID  |  BLOCK  ID  I  BEG  TIME  |  aircraft  count  I 


This  table  contains  density  information  on  the  four-dimensional 
(x,y,z,t)  airspace  block  by  the  subject  aircraft  FL_ID.  The  block 
is  identified  in  the  x,  y,  z  dimensions  by  BL0CK_ID  and  in  the  t 
dimensions  by  BEGJTIME.  The  density  information  consists  of  the 
number  of  aircraft  in  the  block  and  the  corresponding  basic  sector. 

FLJCD  Unique  flight  identifier. 

BL0CK_ID  Unique  identifier  of  an  airspace  block. in  the  x, 

y,  z  airspace  grid. 

BEGJTIME  Beginning  time  of  the  four-dimensional  airspace 

cell. 

aircraft  count  Number  of  aircraft  in  the  four-dimensional  cell. 
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Parameters: 


Sflid 

Flight  id  of  the  subject  aircraft  which 
initiated  SWP. 

Trajecfory_Update_Statu8 

The  update  status  of  the  subject 
aircraft.  Has  a  value  of  ’NEW’  or 
’REVISED. ’ 

APjNot__Dur  . 

The  duration  of  time  prior  to  a  AP 
violation  start  time  that  an  advisory  is 
displayed  to  a  controller. 

Ac_Count_Option 

Flag  set  to  TRUE  when  a.  display  of  average 
aircraft  count  measure  is  desired;  else 
set  to  FALSE. 

FPCP_Encounter_Option 

Flag  set  to  TRUE  when  a  display  of  FPCP 
encounter  count  measure  is  desired;  else 
set  to  FALSE. 

AP_Encounter_Option 

Flag  set  to  TRUE  when  a  display  of  AP 
encounter  count  measure  is  desired;  else 
set  to  FALSE. 

Weighted_Pa_Option 

Flag  set  to  TRUE  when  a  display  of 
weighted  planned  actions  measure  is 
desired;  else  set  to  FALSE. 

Den8ity_0ption 

Flag  set  to  TRUE  when  a  display  of  density 
measure  is  desired;  else  set  to  FALSE. 

Overall_Workload_Option 

Flag  set  to  TRUE  when  a  display  of  overall 
workload  measure  is  desired;  else  set  to 
FALSE. 

DeltaJT 

Size  of  x,y,t  cell  in  the  time  dimension. 

Area_Name 

Name  of  the  area  for  which  workload  is 
being  computed. 

Organ_Type 

Organizational  type  of  "sector"  or  "area" 
for  which  workload  is  being  computed. 

Periodic_Frequency 

Amount  of  time  between  periodic  executions 
of  workload  evaluation. 
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Request_Type  Type  of  workload  evaluation  desired 

(single  execution  or  periodic  executions). 

List_Of_Sectors  (*)  Array  of  sectors  for  which  workload  is 

being  computed. 

Display_Time_Intervals  (*)  Array  of  time-interval  identifiers  for 

which  workload  is  being  computed.  Time 
intervals  are  within  the  Display  Time 
Horizon. 
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APPENDIX  B 


GLOSSARY 

The  number  in  parentheses  at  the  end  of  the  definition  refers  to  the 
section  in  which  the  term  is  first  used. 

AAS  Advancad  Automation  System  (1.1) 

Activation  time  The  time  at  which  the  workload  of  a  planned 

action  is  expected  to  be  performed  (2.1.8) 

Adaptation  Factor  A  numerical  value  used  to  account  .for  the 

differences  in  the  computed  and  expected  values 
or  the  workload  measures  due  to  unpredictable 
features  like  the  quantity  and  quality  of  data 
(2.2.9) 

Advisory  The  criterion  with  which  Flight  Plan  Conflict 

horizontal  Probe  compares  distance  between  aircraft  (2.2.5) 

separation 

criterion 

ASRA  Automated  En  Route  Air  Traffic  Control  (1.4. 1.1) 

AP  Airspace  Probe  (1.1) 

Area  Second  level  division  (see  "Center,"  "Sector") 

of  the  Continental  United  States  airspace. 
Controllers  are  specially  trained  for  an  area's 
airspace,  a  region  bounded  horizontally  by  a 
polygon  and  stretching  vertically  from  the 
center  floor  to  60,000  feet  (1.4.1) 

Area  Manager  The  immediate  superior  of  an  Area  Supervisor 

(1.4.1) 

Area  Supervisor  The  first-line  supervisor  of  an  area  (1.4.1) 

ARTCC  Air  Route  Traffic  Control  Center  (see  "Center") 

(1.4.1) 

ATC  Air  Traffic  Control  (1.3) 
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Basic  sector 

Basic  Sector 
Workload  Measures 
Table 

Block 

Block  density 
airspace  grid 

BSHM  Table 
Cell 

Cell  density 
airspace  grid 

Center 


CPC 

Conbined  sector 


The  smallest  division  of  Continental  United 
States  airspace  (see  "Sector,"  "Area," 
"Center").  A  sector  is  composed  of  one  or  more 
basic  sectors  (1.4.1) 

A  table  in  the  Global  Data  containing  values  of 
workload  measures  for  each  basic  sector  and 
time  interval  from  the  present  to  the  time 
horizon  (3. 1.2.1) 

A  cell  in  the  block  density  airspace  grid 

(2.1.6) 

The  four-dimensional  airspace  grid  whose  cell 
size  in  the  x,  y,  and  t  dimensions  is  twice 
that  of  the  cell  density  airspace  grid,  but 
whose  grid  size  in  the  z  dimension  is  the  same; 
the  grid  stores  the  number  of  aircraft 
occupying  each  cell  (2.1.6) 

BASIC_SECTOR_WORKLOAD_MEASURES  Table  (3.1. 2.1) 

Individual  parallelepipeds  in  (x,y,t)  space 
within  the  airspace  grid  (2.1.6) 

The  four-dimensional  airspace  grid  whose  cell 
size  in  the  x,  y,  and  t  dimensions  is  the  same 
as  the  sector  airspace  grid  and  which  stores 
the  number  of  aircraft  occupying  each  grid  cell 
(2.1.6) 

Administrative  headquarters  and  operational 
facility  for  control  of  a  first  level  division 
(see  "Area,"  "Sector")  of  the  Continental 
United  States  airspace  (there  are  currently  20 
centers);  controls  a  region  bounded 
horizontally  by  a  polygon  and  stretching 
vertically  from  the  center  floor  to  60,000  feet 
(1.4.1) 

Central  Flow  Control  (1.4. 1.2) 

A  division  of  Continental  United  States 
airspace  (see  "Sector,"  "Area,"  "Center")  which 
is  composed  of  one  or  more  basic  sectors  as 
defined  in  the  sectorization  plan  (1.4.1) 


Combined  Sector 
Workload  Measures 
Table 

Component 

Conditional  Mode 

Conditional  Mode 
Request 

Controller 

Controller 

workload 

CSHM 

Delta  Horlson 

Display-as- 
advisory  tine 

Elenent 

EXjOD 

Encounter 


A  table  In  the  Global  Data  containing  values  of 
workload  measures  for  each  combined  sector  and 
time  Interval  from  the  present  to  the  time 
horizon  (3. 1.2.1) 

Third  level  algorithmic  unit  in  breakdown  of 
AERA  (see  "Function,”  "Subfunction,"  "Element") 
(1.3) 

SWF  is  said  to  be  in  Conditional  Mode  when  a 
supervisor  requests  that  sector  workload 
information  be  displayed  when  conditions 
specified  by  him  are  satisfied  (2.1.5) 

A  request  by  a  supervisor  that  information  be 
displayed  when  conditions  specified  by  him  are 
satisfied  (2.1.5) 

In  this  document,  an  en  route  radar  controller 
as  defined  in  "Glossary  of  Common  Terms  in  Air 
Traffic  Control  Operations"  [6]  (1.4.1) 

Work  performed  by  controllers  at  control 
positions;  see  also  "Sector  workload"  (2.1.9) 

COMBINED  SECTOR  WORKLOAD  MEASURES  Table 
(3.1.2.17 


The  period  between  consecutive  updates  of  the 
time  horizon  (2.1.1) 

The  time  at  which  an  advisory  message  is  first 
displayed  to  a  controller  (2.2.5) 

Fourth  level  algorithmic  unit  in  breakdown  of 
AERA  (see  "Function,"  "Subfunction," 
"Component")  (1.3) 

En-Route  Sector  Loading  (1.4. 1.2) 

A  nominee  whose  horizontal  distance  from  the 
subject  aircraft  is  less  than  a  threshold 
(i.e.,  it  violates  the  advisory  horizontal 
separation  criteria)  (2.1.7) 
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Encounter-status- 
changed  aircraft 

ESC 

ESC  Tables 

FM 

Fix 

FPCP 

FPCP  Fine  Filter 

Function 

Global  Data 

Grid  cell 
Grid  chain 

Holding  pattern 

Horizon  update 
IAW  Table 


Aircraft  whose  status  has  changed  between 
encounters  and  non-encounters,  or  whose 
location  of  encounter  or  display  time  has 
changed  (4.1. 1.1) 

Encounter-status-changed  (4 . 1 . 1 . 1) 

Refers  to  both  ESC  Increment  Table  and  ESC 
Decrement  Table  whose  records  contain  sector- 
time-intervals  with  encounters  created  or 
deleted,  respectively,  due  to  trajectory 
updates  (4. 1.1. 2. 2) 

Federal  Aviation  Administration  (1.1) 

A  specified  point  on  an  aircraft's  route  used 
for  navigation  (1.4. 1.2) 

Flight  Plan  Conflict  Probe  (1.1) 

An  algorithm  that  tests  subject-nominee  segment 
pairs  against  FPCP  separation  criteria  using 
rigorous  mathematical  analyses  (2.2.6) 

A'  major  building  block  of  AERA — a  principal 
algorithm  which  is  the  top  level  unit  in  the 
breakdown  of  AERA  (see  "Subfunction, M 
"Component,"  "Element")  (1.1) 

The  set  of  data  used  by  more  than  one  AERA 
function  or  which  is  input  to  or  output  from 
AERA  (3. 1.2.1) 

Same  as  "Cell"  (2.1.6) 

The  set  of  cells  occupied  by  an  aircraft's 
trajectory  (2.- 1.6) 

An  aircraft  maneuver  to  delay  its  en  route 
progress;  usually  a  circling  or  spiraling 
within  a  specified  airspace  (2.r.8) 

Same  as  SWP  horizon  update  (2.1.1) 

Individual  Aircraft  Workload  Table  (4. 1.1.1) 
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Immediate  Mode 

Tm  Hate  Mode 
Request 

Measure 

NAS 

NASP 

Nominee 

Object 

Occupied  cell 

PDL 

Planned  action 

Radar  controller 
Re synchronisation 

RSW  Table 
Sector 


SWP  is  said  to  be  in  Immediate  Mode  when  a 
supervisor  requests  an  immediate  display  of 
sector  workload  information  (2.1.5) 

A  request  by  a  supervisor  for  the  immediate 
display  of  sector  workload  Information  (2.1.5) 

Same  as  "Workload  measure"  (1.4.1) 

National  Airspace  System  (1.1) 

National  Airspace  System  Plan  (1.1) 

In  the  Flight  Plan' Conflict  Probe,  an  object 
aircraft  that  occupies  the  same  .or  an  adjacent 
cell  as  the  subject  aircraft  and  whose  altitude 
limits  overlap  those  of  the  subject  (2.1.7) 

An  aircraft  (which  is  not  the  subject)  whose 
current  trajectory  has  already  been  processed 
by  FPCP  (2.1.4) 

A  cell  satisfying  certain  FPCP  or  SWP  criteria 
relative  to  a  trajectory  (2.1.6) 

Program  Design  Language  (1.2) 

Any  of  a  set  of  actions  that  can  be  anticipated 
for  an  aircraft  based  on  its  trajectory  (2.1.8) 

Same  as  "Controller"  (1.4.1) 

Recomputation  of  the  estimated  aircraft 
trajectory  when  the  trajectory  is  inconsistent 
with  the  aircraft' 8  recent  radar  track  history 
(1.5.2) 

Revised  Subject  Workload  Table  (4. 1.1.1) 

Third  level  division  (see  "Center,"  "Area," 
"Basic  Sector")  of  the  Continental  United 
States  airspace  to  which  a  controller'  is 
assigned;  a  region  bounded • horizontally  by  a 
polygon  and  stretching  vertically  from  the 
center  floor  (the  ground  or  a  specified 
altitude)  to  a  ceiling  altitude  (1.4.1) 
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Sector  Airspace 
Grid 


Sector-tlae- 

interval 


Sector  workload 


Sectorization 


Sectorization  plan 

Seetorirction 

schedule 

Subfunction 


Subject 


Subject  Aircraft 

Workload 

Subfunction 

Subneaaure 


Supervisor 


Supervisor 

Requests 

Subfunction 

SWP 

SWP  display  tiae 
horizon 


Grid  dividing  the  horizontal  dimensions  of  the 
planning  region  over  time  into  discrete  cells 
(2.1.6) 

Portions  of  a  trajectory,  the  beginning  and  end 
of  which  are  at  times  either  when  the  aircraft 
enters  a  new  sector  or  when  a  new  time-interval 
begins  (3,3.1) 

Tasks  performed  in  a  sector;  see  also 
"Controller  workload”  (2.1.9) 

The  process  of  combining  or  decombining  sectors 
(see  "Sector")  (1,4.1) 

A  way  in  which  basic  sectors  can  be  combined 
via  sectorization;  see  "Sectorization”  (2.1.2) 

The  current  sectorization  plan  and  the  sectori¬ 
zation  plans  and  their  planned  times  of 
implementation  through  the  time  horizon  (2.1.3) 

Second  level  unit  in  the  breakdown  of  AERA  (see 
"Function,"  "Component,"  "Element”)  (1.3) 

The  aircraft  whose  new,  updated,  revised,  or 
alternative  (trial  probe)  trajectory  is 
currently  being  tested  by  FPCP  (2.1.4) 

The  subfunction  of  SWP  which  updates  workload 
data  on  the  subject  aircraft  (3.0) 


The  finest  subdivision  of  calculated  workload 
(2.1.9) 

Either  an  Area  Supervisor  or  an  Area  Manager 
(1.4.1) 

The  subfunction  of  SWP  that  receives  and 
processes  certain  data  entered  by.  the 
supervisor  (3.0) 

Sector  Workload  Probe  (1.1) 

The  maximum  length  of  time  into  the  future  for 
which  SWP  values  are  displayed  (2.1.1) 
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SWF  horizon  update 


SWP  trajectory 
update 

Time  Horizon 

Time-interval 

Time-interval 

duration 

TJE 

Trajectory 

Trajectory  update 
Vector 

Workload 

Workload  aeaaure 


An  activation  of  SWP  to  evaluate  workload  for 
new  portions  of  trajectories  (2.1.1) 

One  of  four  events:  1)  a  trajectory  is  added, 
2)  a  trajectory  is  resynchronized,  3)  a 
trajectory  is  amended,  or  4)  a  horizon  update 
occurs  (2.1.3) 

The  length  of  time  into  the  future  for  which 
SWP  evaluates  its  workload  measures  (2.1.1) 

A  unit  of  time  for  which  workload  is  computed 

(2.1.1) 

The  length  of  time  in  a  time  interval;  the  unit 
in  time  for  computing  workload  in  a  sector 
(2.1.1) 

Trajectory  Estimation  (1.1) 

Description  of  an  aircraft’s  position  in 
(x,y,z,t)  space,  produced  by  applying  altitude 
and  timing  assumptions  to  the  filed  flight  plan 
and  revised  when  necessary  (1.5.2) 

Same  as  "SWP  trajectory  update"  (2.1.3) 

Controller-directed  maneuver  to  provide  an 
aircraft  with  a  change  in  route  (2.1.8) 

Any  task  performed  by  personnel  to  provide  air 
traffic  control  services  to  aircraft  (1.4) 

A  mathematical  function  that  assigns  a 
numerical  value  to  one  or  more  aspects  of 
workload  (1.4.1) 
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APPENDIX  C 


AERA  PDL  LANGUAGE  REFERENCE  SUMMARY 


C.l  Overview  of  the  Use  of  AERA  PDL 


The  AERA  Program  Design  Language  (PDL)  has  been  created  for  the 
single  purpose  of  presenting  algorithms  In  this  specification 
document.  It  evolves  from  previous  AERA  uses,  and  from  MITRE 
WP-S1W552,  "All  About  E,"  October  1981. 

The  description  of  this  appendix  Is  Intended  to  support  readers  and 
usere  of  AERA  PDL.  AERA  PDL  supports  readable,  yet  structured  and 
consistent,  descriptions  of  algorithms. 

AERA  PDL  Features 


•  Relational  data  tables  can  be  defined  and  manipulated  by 
constructs  In  the  language. 

•  Bulltln  functions  are  used  to  provide  routine  calculations 
without  showing  all  of  the  detail. 

•  Routines  are  used  to  modularize  logic  paths  and  data  scope. 

•  Indentation  Is  used  to  Indicate  statement  grouping, 
statement  continuation,  and  levels  of  nesting. 

•  Routines  explicitly  define  data  or  refer  to  predefined  data. 

AERA  PDL  Statements 


The  types  of  statements  used  In  AERA  PDL  are: 

•  English  language  statements 

•  assignment  statements 

•  routine  declaration  statements 

•  data  manipulation  statements 
«  flow  of  control  statements 

C.2  Elements  of  AERA  PDL 

Keywords 

Keywords  are  words  reserved  for  the  usage  of  AERA  PDL.  Figure 
. C— 1  presents  all  the  keywords  used  In  the  current  version  of 
ASIA  PDL,  grouped  for  convenience. 


routine  construction  keywords 


CALL  END 

data  reference  keywords 


ROUTINE 


PARAMETERS  IN 

REFER  TO  GLOBAL  OUT 

REFER  TO  SHARED  LOCAL  INPUT 

DEFINED  IN  GLOSSARY 


data  definition  keywords 

DEFINE  CONSTANT(S) 
DEFINE  VARIABLE(S) 
DEFINE  TABLE(S) 


common  arithmetic  bulltln  function  keywords 


AVG 

MIN 

ABS 

EXP 

COS 

ARCCOS 

SUM 

MAX 

CEIL 

LOG 

ARCSIN 

MEDIAN 

FLOOR 

SQRT 

TAN 

ARCTAN 

SIGNUM 

MOD 


coordinate  geometry  bulltln  function  keywords 

DIST  DOT  INTERSECTION 

MAGNITUDE  CROSS  INTERPOLATE 

DIRECTION  LINE 

set  bulltln  function  keywords 

UNIQUE  COUNT  CONCAT  BOOL 


FIGURE  C-l 
KEYWORD  GROUPINGS 


set  operator  keywords 


UNION  INTERSECT 
table  manipulation  keywords 


SELECT  FIELDS 

ALL 

INSERT .INTO 

FROM 

DELETE  FROM 

INTO 

UPDATE  IN 

WHERE 

ORDERED  BY 
RETURN  COUNT 


value  constant  keywords 

'  TRUE 

FALSE 

NULL 

comparison  keywords 

NOT 

GT 

m 

OR 

GE 

NE 

AND 

LT 

IS  IN 

LE 

IS  NOT  IN 

flow  of  control  keywords 


IF  ...  THEN  ...  ELSE 

CHOOSE  CASE  ...  WHEN  ...  THEN  ...  OTHERWISE 
FOR  ...  TO 
REPEAT  WHILE 
REPEAT  UNTIL 

REPEAT  FOR  EACH  ...  RECORD 
GO  TO 


FIGURE  C-l  (Concluded) 
XEYWORD  GROUPINGS 
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Operators 

The  operators  of  AERA  PDL  are  summarized  in  Figure  C-2. 

The  Assignment  Operator 

•  The  format  of  the  assignment  statement  is: 

"target"  *  "expression" 

•  The  target  may  be  any  type  of  data  allowed  by  AERA  PDL. 

•  The  assignment  operator  includes  the  ability  to  fill  a  table 
from  data  contained  in  other  tables.  The  form  of  this  use 
of  the  assignment  operator  is:  ■ 

"table_name"  **  "tablejexpression"  ; 

Bulltln  Functions 

The  bulltin  functions  of  AERA  PDL  accept  either  an  single  value 
or  data  organized  into  an  array.  The  author  of  a  routine  must 
make  it  clear  in  comments  and  text  what  form  of  data  is  being 
processed  by  the  bulltin  function.  Builtin  functions  are 
listed  in  Figure  C-3. 

C.3  Routine  Construction 


The  order  of  appearance  of  constructs  in  a  routine  is: 

•  ROUTINE  —  required 

•  PARAMETERS  —  optional 

•  REFER  TO  GLOBAL  —  optional 

•  REFER  TO  SHARED  LOCAL  —  optional 

•  DEFINED  IN  GLOSSARY  —  optional 

•  DEFINE  CONSTANTS  —  optional 

•  DEFINE  VARIABLES  —  optional 

•  DEFINE  TABLES  —  optional 

•  logic  flow  «—  required,  but  will  vary  by  routine. 

•  END  —  required 

Three  of  the  constructs  are  noted  below: 

The  ROUTINE  Construct 

•  The  ROUTINE  construct  names  the  routine. 

•  The  syntax  of  the  ROUTINE  construct  is: 

ROUTINE  "routinejname"  ; 
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» 


A  18  assigned  the  value  of  B 


assignment  operator 
A  -  B 

arithmetic  operators 

A  +  B 
A  -  B 
A  *  B 
A  /  B 
A  **  B 

comparison  operators 


A  plus  B 
A  minus  B 
A  times' B 
A  divided  by  B 
A  to  the  power  of  B 


A  LT  B 
A  LE  B 
A  GT  B 
AGE  B 
A  EQ  B 
A  NE  B 


logical  operators 

NOT  A 
A  OR  B 
A  AND  B 

set  operators 


A  is  less  than  B 
A  is  less  than  or  equal  to  B 
A. is  greater  than  B 
A  is  greater  than  or  equal  to  B 
A  is  equal  to  B 
A  is  not  equal  to  B 


Ihe  logical  opposite  of  A 
Logical  OR  of  A  and  B 
Logical  ASP  of  A  and  B 


A  INTERSECT  B 
A  UNION  B 
a  iSTn  b 

A  IS  NOT  IN  B 


The  set  intersection  of  A  and  B 
The  set  union  of  A  and  B 
A  is  an  element  of  the  set  B 
A  is  not  an  element  of  the  set  B 


FIGURE  C-2 

GROUPINGS  OP  AERA  PUL  OPERATORS 
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FUNCTION 


MEANING 


ABS(x) 

Absolute  value  of  x 

ARCCOS(x.y) 

Inverse  cosine  of  the  ratio  of  y  to  x 

ARCSIN(x.y) 

Inverse  sine  of  the  ratio  of  y  to  x 

ARCTAN(x,y) 

Inverse  tangent  of  the  ratio  of  yto  x 

AVG(A) 

Mean  of  the  elements  in  A 

aOOL(x) 

Numerical  equivalent  of  logical  condition: 

1  if  x  is  TRUE,  0  if  x  is  FALSE 

CEIL(x) 

Smallest  integer  greater  than  or  equal  to  x 

C0NCAT(sl,s2,...fsN) 

Concatenation  of  strings  si  through  sN 

COS (x) 

Cosine  of  x 

COUNT(A) 

Number  of  elements  of  a  set  A 

CROSS (vl,v2) 

Cross  product  of  vectors  vl  and  v2 

DIRECTION(plf  p2) 

Direction  of  p2  from  pi  in  degrees  from  the 
north;  usually  will  be  expressed  in  degrees 
clockwise  from  true  north 

DIST(pl,p2) 

Euclidean  distance  between  points  pi  and  p2 

D0T(y1,v2) 

Dot  product  of  vectors  vl  and  v2 

EXP(x) 

e  to  the  x  power 

FLOOR(x) 

Greatest  Integer  less  than  or  equal  to  x 

FIGURE  C-3 
BUILTIN  FUNCTIONS 
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FUNCTION 


MEANING 


INTHtPOLATE(a,b,t) 

INTERSECTION(Ll,L2) 

LINE(pl,p2) 

LOG(x) 

MAGNITUDE(v) 

MAX(A) 

MEDIAN(A) 

MIN(A) 

M0D(xl,x2) 

PROD(A) 

SIGNUM(x) 

SIN(x) 

SQRI(x) 

SUM(A) 

TAN(x) 

PNIQPE(A) 


The  point  (l-t)a+tb 

3he  point  of  intersection  of  the  lines  Ll  and 
L2 

Vector  (a,b,c)  corresponding  to  the  line 
ax  +  by  ■  c  which  passes  through  the  points 
pi  and  p2 

Log  of  x  in  base  e 

Length  (i.e.,  norm)  of  the  vector  v 

Largest  of  the  elements  in  the  set  A 

Median  value  of  the  elements  in  set' A 

Smallest  of  the  values  in  set  A 

Remainder  when  xl  is  divided  by  x2 

Product  of  the  elements  in  A 

Function  yielding  1  if  x  GT  0,  -1  if  x  LT  0, 
and  0  if  x  EQ  0 

Sine  of  x 

Square  root  of  x 

Sum  of  the  elements  in  A 

Tangent  of  x 

The  set  A  with  no  duplicate  elements 


FIGURE  C-3  (Concluded) 
BUILTIN  FUNCTIONS 
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The  CALL  Construct 


•  The  CALL  construct  invokes  use  of  another  routine  as  a 
subroutine  and  passes  to  it  the  data  on  which  it  is  to 
operate . 

•  The  syntax  of  the  CALL  construct  is: 

CALL  "routine^name"  (  "data_usage_list”  )  j 

•  The  data  usage  list  in  the  CALL  statement  must  match  in 
number  and  data  utilization  (IN,  OUT,  INPUT)  the  PARAMETERS 
statement  of  the  called  routine. 

The  END  Construct  ‘  •  >' 


•  The  END  construct  shows  the  formal  end  of  the  routine. 

■ •  The  syntax  of  the  END  construct  is: 

END  "routinejaame"  ; 

C.4  Data  Definitions 


Data  usage  is  defined  in  the  constructs  placed  at  the  beginning  of 
each  routine. 

The  structures,  or  organization  of  data,  recognizable  to  AERA  PDL 
Include  constants,  atomic  variables,  hierarchically  structured 
variables,;  arrays,  tables,  and  field-types.  The  hierarchically 
structured  variables  are  the  same  as  the.  structure  variables  of  PL/I. 

Within  a  table,  the  values  corresponding  to  the  definition  of  a 
field-type  are  called  fields  when  they  are  referred  to  individ¬ 
ually.  The  values  for  a  whole  column  of  a  table  (or  a  subset  of  the 
whole  column)  may  be  referred  to  as  a  set  of  fields. 

The  following  data  definition  constructs  appear  in  the  order  shown, 
if  any  are  needed.  The  first  line  of  each  construct  begins  in 
column  1,  aligned  with  the  ROUTINE  construct. 

The  PARAMETERS  Construct 


•  This  construct  provides  usage  information  about  the  data 
that  are  being  provided  by  the  calling  routine  in  the  form 
of  specification  of  read-only  ’IN* ,  write-only  'OUT* ,  or 
modification  of  an  existing  value  * INPUT* . 
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•  Variables  appearing  in  the  PARAMETERS  construct  are  still 
local  data  for  the  routine  being  defined  and  as  such  appear 
in  the  definition  constructs. 

•  The  syntax  of  the  PARAMETERS  construct  is: 

PARAMETERS  "data_usage_list"  ; 

The  REFER  TO  GLOBAL  Construct 


•  This  construct  provides  reference  to,  and  usage  infornation 
for,  data  from  the  Global  data  model. 

•  The  syntax  of  the  REFER  TO  GLOBAL  construct  is: 

REFER  TO  GLOBAL  "data_usage_list"  ; 

The  REFER  TO  SHARED  LOCAL  Construct 


•  This  construct  provides  reference  to,  and  usage  information 
for,  data  from  the  Shared  Local  data  model  described  in 
Appendix  A  of  the  specification. 

•  The  syntax  of  the  shared  local  construct  is: 

REFER  TO  SHARED  LOCAL  "data_UBage_list"  ; 

The  DEFINED  IN  GLOSSARY  Construct 

•  This  construct  provides  reference  to,  and  usage  Information 
for,  data  from  a  specially  prepared  Glossary  that  central¬ 
izes  the  definition  of  data  variables  that  are  used  re¬ 
peatedly  within  a  given  function  of  the  algorithmic 
specification. 

•  The  syntax  of  the  shared  local  construct  is: 

DEFINED  IN  GLOSSARY  "datajisageJList"  ; 

The  DEFINE  CONSTANTS  Construct 


•  The  use  of  named  constants  Instead  of  in-line  numerical 
constants  is  available  at  the  discretion  of  the  author  of  an 
algorithm.  Named  constants,  if  present,  are  to  be  declared 
with  this  construct. 

•  The  syntax  of  the  DEFINE  CONSTANTS  construct  is: 

DEFINE  CONSTANTS  "constant  definition  block"  ; 


Hie  DEFINE  VARIABLES  Construct 


•  Hie  syntax  of  the  DEFINE  VARIABLES  construct  is: 

DEFINE  VARIABLES  ,,variable_definition_block"  ; 

The  DEFINE  TABLES  Construct 

•  Hie  syntax  of  the  DEFINE  VARIABLES  construct  is: 

DEFINE  TABLES  "table_definitlon_block" ; 

C.5  Flow  of  Control  Constructs 

Hie  IF. . .THEN. . .ELSE  Construct 

•  Hie  syntax  of  the  IF. . .THEN. . .ELSE  construct  is: 

IF  "condition" 

THEN 

"s tatement_blo ck " 

[  ELSE 

"statement_block"  ] 

The  CHOOSE  CASE  Construct 


•  This  construct  provides  a  choice  of  one  of  several  alterna¬ 
tive  logic  paths  depending  on  the  first  condition  satisfied 
among  the  conditions  specified. 

•  Hie  OTHERWISE  phrase  Is  optional. 

•  Hie  syntax  of  the  CHOOSE  CASE  construct  is: 

CHOOSE  CASE 

WHEN  "condition"  THEN 
*8  tateaent_blockw 

[  WHEN  phrases  repeated  as  necessary  ] 

[  OTHERWISE 

w8tatement_block”  ] 

The  REPEAT  WHILE  Construct 


*  Hie  syntax  of  the  REPEAT  WHILE  construct  is: 
REPEAT  WHILE  "condition"  ; 
w8tatement_block" 

The  REPEAT  UNTIL  construct 


•  Hie  syntax  of  the  REPEAT  UNTIL  construct  is: 
REPEAT  UNTIL  "condition"  ; 

“statement  block" 
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The  REPEAT  FOR  EACH  RECORD  Construct 


•  31x1s  construct  explicitly  loops  over  all  records  In  table, 
or  the  subset  of  a  table  as  specified  in  a  WHERE  phrase. 

•  3he  syntax  of  the  REPEAT  FOR  EACH  construct  is: 

REPEAT  FOR  EACH  "table  name"  RECORD 
[  WHERE  "condition"  ]  ; 

"statement_block" 

•  Within  the  statement  block  of  this  loop,  the  construct  of 
"table_name" . "f ield_name"  means  only  the  ONE  value  that  is 
associated  with  the  record  for  that  iteration  of  the  loop. 

•  If  it  is  necessary  to  refer  to  entire  columns  of  the  table 
that  is  being  looped  on,  the  correct  form  of  the  reference 
is  ALL("table__name"."field_name").  This  construct  means 
exactly  what  "table_name"."field_name"  would  have  meant  if 
the  loop  had  not  been  in  effect. 

Hie  GO  TO  Construct 


•  The  syntax  of  the  GO  TO  construct  is: 
GO  TO  "label"  ; 

The  FOR... TO...  Construct 


•  The  syntax  of  the  FOR. . .TO. . .  construct  is: 

FOR  "loopjlndex"  ■  "initial_value"  jK)  "last__value"  ; 
"etatement_block" 

C.6  Table  Manipulation  Constructs 
The  SELECT  FIELDS  Construct 


•  This  construct  extracts  data  from  a  table,  or  from  a  collec¬ 
tion  of  tables,  and  makes  it  available  to  the  routine. 

•  The  syntax  of  the  SELECT  FIELDS  construct  is: 

SELECT  FIELDS  [  UNIQUE  ]  [  "field  list"  |  ALL] 

EftOk  Stable  name  11s  t " 

[  INTO  "local~variable  nameJList"  ] 

[  WHERE  "condition"  ]  “ 

[  ORDERED  BY  "fieldjiame"  ] 

[  RETURN  COUNT  (  "local  variable"  )  ]  j 
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The  INSERT  INTO  Construct 


•  Ihis  construct  allows  a  new  record  to  be  Inserted  Into  a 
table. 

•  The  syntax  of  the  INSERT  INTO  construct  is: 

INSERT  INTO  "table  name"  ("field  assignments") 
t  WHERE  "condition" ]  ; 

•  All  Insertions  will  preserve  the  assumption  of  no  duplicate 
records  allowed  in  the  table. 

The  UPDATE  IN  Construct 


•  This  construct  allows  existing  records  in  a  table  to  have 
certain  of  their  values  changed. 

•  The  syntax  of  the  UPDATE  IN  construct  is: 

UPDATE  IN  "table  name"  .("field  assignments") 
t  WHERE  "condition"  ]  j 

The  DELETE  FROM  Construct 


•  Ihis  construct  removes  selected  records  from  a  table. 

•  The  syntax  of  the  DELETE  FROM  construct  is: 

DELETE  FROM  "table i_name" 
t  WHERE  "condition"  ]  j 

C.7  Glossary 

"comparison" 

•  There  are  four  possible  syntaxes  for  the  comparison.  These 
are  not  given  separate  names,  but  will  all  be  shown  as  if 
they  shared  the  same  element  of  the  language. 

•  The  first  syntax  is  for  arithmetic  comparisons: 

"individual"  GE|L£|gt|LT  "individual" 

•  The  second  syntax  is  for  general  comparisons: 

"individual"  EQ I NE  "individual" 

•  Both  of  these  syntaxes  are  also  valid  if  they  are  used  to 
compare  two  variables  with  the  same  complex  organization, 
for  example  two  vectors  of  the  same  length  or  two  field 
types  from  the  same  table.  In  this  case  the  result  has  as 
many  answers  as  there  are  elements  in  the  compared  variables. 
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•  The  third  syntax  is  for  arithmetic  comparisons: 

"individual"  GEjLEiGTiLT  ANY | ALL  "set" 

•  Ihe  fourth  syntax  is  for  general  comparisons: 

"individual"  IS  IN I IS  NOT  IN  "set" 

•  The  latter  two  syntaxes  are  used  to  qualify  ary-individual 
based  on  any  value  in  a  set  of  values. 

"condition" 


•  The  syntax  of  the  condition  is: 

"comparison"  [AND [AND  N0T|0R|0R  NOT  "comparison"] 

•  The  optional  part  of  this  syntax  can  be  repeated  as  often  as 
required . 

"constant  definition  block" 


•  The  content  of  the  constant  definition  block  is  three 
columns:  the  constant  names,  the  constant  values,  and  the 
constant  descriptions. 

•  The  constant  names  are  aligned  in  a  column  3  spaces  Indented 
from  the  DEFINE  CONSTANTS  line. 

•  The  other  two  columns  are  aligned  as  convenient,  so  that 
there  is  no  visual  overlap  between  the  columns. 

"data  usage  list" 


•  A  routine  must  declare  the  type  of  use  for  all  of  its  data 
that  are  known  outside  the  routine. 

•  The  three  types  of  use  are:  read  only  (IN),  create  (OUT), 
and  modify  an  existing  copy  (INPUT). 

•  The  format  of  a  data  usage  list  is: 

"varlabl e__name "  "usage_type",  ... 

•  An  example  of  the  format  for  data  usage  list  is: 

An_Input_Parameter  IN,  A_LOCAL_TABLE  INPUT 

"expression" 

•  Variables  may  be  formed  implicitly  in  expressions  without 
being  separately  named  or  defined. 
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•  Expressions  are  combinations  of  defined  variables  with  the 
operators  and  builting  functions  of  AERA  FDL. 

•  In  an  expression,  the  implicit  variable  output  from  any 
builtin  function  may  be  used  as  the  input  to  any  other 
builtin  function  or  operator. 

•  An  expression,  when  fully  evaluated,  yields  one  variable. 

"field  assignments" 

•  This  tem  only  appears  in  statements  referring  to  exactly 
one  table:  INSERT  and  UPDATE. 

•  Hie  form  of  the  term  is  a  comma-separated  list: 

"f ield_asslgnment ",  ... 

•  Hie  form  of  a  single  assignment  is: 

"field_name"  -  "value_expression" 

•  In  this  term  the  field_names  do  not  have  to  be  qualified  by 
the  table  name  (that  is  given  in  the  statement). 

"table  definition  block" 


•  Three  types  of  definition  are  made  in  this  block:  table  defi¬ 
nitions,  field-type  definitions,  and  AGGREGATE  definitions. 

•  Table  definition  lines  are  formatted  as: 

"table_name"  "tablejdefinition" 

•  Field-type  definitions  lines  are  formatted  as: 

"fleld_name"  "field_definition" 

•  Aggregate  definitions  are  formatted  as: 

"aggregate_name"  AGGREGATE  ("field_name_list") 

•  Fields  will  contain  only  atomic  (single-valued)  variables. 

•  Aggregates  may  be  used  so  that  a  program  can  manipulate 
multiple  fields  in  one  statement  when  it  makes  sense  to  do 
so. 

" table-expre  s  s ion" 

•  Tables  may  be  used  implicitly  in  assignments  or  comparisons 
being  separately  named  or  defined. 
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•  A  table  expression  is  either  a  table  name  or  a  SELECT  state¬ 
ment  specifying  the  contents  of  the  implicit  table. 

"table  name" 


•  Generally,  this  is  just  the  name  of  a  table. 

•  In  a  few  statements,  there  is  a  syntax  that  allows  a  user  to 
define  a  synonym  and  use  it  in  the  rest  of  that  statement. 
The  intent  of  this  option  is  to  allow  shorter  where  clauses 
that  are  easier  to  read.  The  format  of  the  synonym  refer¬ 
ence  is: 

"existing_table_name"  (  "synonym"  ) 

•  Ihe  statements  that  allow  this  use  are  those  that  have  the 
where  clause:  SELECT,  INSERT,  DELETE,  UPDATE,  and  REPEAT. 

"variable  definition  block" 


•  Ihe  content  of  the  variable  definition  block  is  two  columns: 
variable  names  and  variable  descriptions. 

•  Align  variable  names  in  a  column  that  is  indented  3  epaces 
from  the  DEFINE  VARIABLES  line. 

•  Align  variable  definitions  in  a  column  as  convenient;  when  a 
structure  element  is  defined,  both  the  variable  name  and  the 
variable  definition  should  be  indented  three  spaces  from  the 
name  and  definition  of  the  next  higher  level  variable. 

•  Ihree  types  of  variables  may  be  defined  in  this  block: 
atomic  variables,  arrays,  and  structured  variables. 

•  Each  element  variable  Is  described  by  a  line: 

"variablejaame"  "variablejdefinition" 

•  Each  array  variable  is  described  by  a  line: 

"va ria bl e_nam e "  ("dimensions")  "variablejdefinition" 

•  Each  structured  variable  is  described  by  multiple  lines,  one 
line  per  lowest  level  element,  and  one  line  for  each  named 
level  of  grouping/structure,  with  indentation  levels  used  to 
indicate  the  grouping. 

•  Ihe  names  of  subordinate  elements  of  a  structured  variable 
are  named  in  all  lower  case  letters. 


•  Hie  use  of  complex  structured  variables  is  not  encouraged; 
one  reasonable  use  for  them  is  to  receive  the  values  of 
AGGREGATES. 

C.8  Other  Uses  and  Conventions 


Use  of  Special  Characters  in  AERA  PPL 

•  Parentheses  are  used  for  grouping  statements  and  setting  off 
special  parts  of  the  constructs. 

•  Semicolons  are  used  as  statement  terminators. 

•  Colons  are  used  to  terminate  labels. 

•  Underscore  is  used  to  separate  words  in  multi-word 
identifiers. 

t  The  symbols  and  */*  are  used  as  arithmetic 

operators. 

•  The  pound  sign  is  used  as  a  comment  delimiter,  for 
beginning  and  end  of  each  comment  line. 

•  Commas  are  used  as  separators  in  lists  of  operands. 

•  Periods  are  used  to  separate  fully  qualified  names. 

Naming  Conventions 

•  Keyword  identifiers  use  only  uppercase  letters  and  are 
underlined.  They  are  the  only  underlined  identifiers  in  the 
PDL. 

•  Table  identifiers  from  the  relational  data  base  also  use 
only  uppercase  letters. 

•  AGGREGATE  identifiers  for  combinations  of  fields  use  no 
uppercase  letters. 

•  References  to  fields  in  a  table,  used  in  the  normal  course 
of  reference  in  AERA  PDL,  will  be  fully  qualified  by 
Including  the  table  name. 


Other  Identifiers 


•  Identifiers  for  constants,  routines,  labels,  arrays,  and 
hierarchically  structured  variables  are  all  be  named  using 
word-initial  capitals. 

•  For  hierarchically  structured  variables,  all  of  the  sub¬ 
ordinate  elements  within  the  structure  use  only  lowercase 
letters. 

•  For  hierarchically  structured  variables,  all  references  to 
the  subordinate  elements  in  the  structure  will  be  in  fully 
qualified  form  using  separate  identifiers. 

•  Global  data  and  shared  local  data  can  include  both  tables 
and  parameters.  The  individual  parameters  are  named  using 
word-initial  capitals. 

Use  of  the  Formal  Constructs  in  AERA  PPL  Statements 

•  Statements  may  use  formal  constructs  or  clear  English 
descriptions  to  specify  the  intended  test  or  action. 

•  Any  AERA  PDL  statement  is  terminated  by  a  semicolon, 
Including  any  English  statement  outside  of  a  comment. 

•  Below  the  level  of  statement,  some  statements  have  a  finer 
organization  in  terms  of  "phrases",  usually  occupying  a  line 
per  phrase  and  indented  one  level  from  the  first  line  of  the 
original  statement. 

Statement  Organization 

•  Indentation  is  used  to  indicate  statement  grouping, 
statement  continuation,  and  levels  of  nesting. 

•  Any  statement  may  have  a  label  starting- in  column  1. 

•  Continuation  lines  are  Indented  three  spaces  from  the 
original  line  of  the  statement. 

•  Comments  are  used  as  needed,  bracketed  by  th'»  special 
character 
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